Thread View: comp.sys.next.programmer
2 messages
2 total messages
Started by nevin
Wed, 18 Nov 1992 21:13
Re: Coding Rules/Suggestions (RTF)
Author: nevin
Date: Wed, 18 Nov 1992 21:13
Date: Wed, 18 Nov 1992 21:13
360 lines
19970 bytes
19970 bytes
In comp.sys.next.programmer article
<1992Nov14.203954.19528@dtint.uucp> you wrote:
> I'm hoping to stimulate a lively discussion on this.
>
> I'll start out with my own list. Tell me what you think...
>
> Coding Rules and Suggestions for the NeXT
> by Nevin Pratt
> nevin@dtint.dtint.com
Interesting stuff and a lot of good point, some of which end up being
applicable only to the NeXT environment. Consider what kind of
porting problems you may run into if you implement your standards.
More that a particular standard, it probably is important for a group
of people to agree on a standard implementation. This includes
subproject setup, object naming conventions, code outlining, file
commenting and organization, method/function commenting, line or
cluster commenting, etc.
I've been the route of extremely strict conventions (see Charles
Symoni, MIT/Microsoft on type naming calculus commonly referred to as
"Hungarian"), and I find the middle ground more appealing (i.e. a
'relaxed' but enforceable, democratic group of standards).
> All panels and windows should be in a separate NIB file, one per
NIB, with a separate Class object to control and manage each NIB.
For example, for the Info NIB file, there should also be files Info.h
and Info.m that manages the NIB file. The panel or window in the NIB
file should have the name of it's NIB file (and associated class
files) as the name of the panel/window (this is setable via the
Inspector panel of I.B. I'm talking about the name that will appear
in the title bar of the panel/window, not the name as it might appear
in the "Objects" part of the NIB).
This doesn't account for sub-panels or micro-panel management. Also,
if you have a large collection of NIBs it means a propagation of
objects/classes. Again, a standard method within the application may
be what's really called for, not a standard approach to all
applications.
>
> Or, at the very least, the name of the NIB file (and therefore the
associated class files) should be obvious to determine simply by
looking at the panel (or window) name. In this way, simply running
the program will give another programmer a very good idea of the
object structure of the program, since he can plainly see all of the
panels and windows, and their names, while the program is running.
Again, many nibs don't show titles. Another (possible) consideration:
information hiding. If you are distributing source for public
consumption then is probably not what you want to do. If you are
selling an application, you may wish to encode some things. Some
venders do consider it appropriate.
> *****************************
>
> When given a choice of fewer objects that do more, versus more
objects that are smaller and do less, favor the use of smaller
objects. You'll find that your objects will grow larger during
development anyway.
Generally I'd agree. However, if you're talking about managing say,
1000 classes, you'll find a certain redundancy starts to creep in.
OOP in general has to do with the management of information. Do you
want to manage more or less things within a file? Do you want to
manage more or less things among files?
People are still enamored enough with OOP enough to not see the
second situation: objects allow a encapsulization of related code so
we can avoid situations of tightly wrapped coding. Object systems
still end up being tightly bound among sets of objects. OOP has not
'solved' the problem, only pushed it further back, at which stage the
problem becomes even bigger. Consider the impacts of favoring smaller
objects when your objects become interdependent and abundant.
I'm neither for or against large/small objects; I'm for applying what
best suits the big picture.
>
> *****************************
>
> I have not, as yet, seen a single convincing situation where public
instance variables were necessary or even desirable, although I am
hesitant to say that there are none. ...
Unless otherwise convinced for special occassions, all instance
variables should only be modifiable by a class method (i.e., NOT be
public). It should also not be modifiable by more than one class
method.
It depends on how "purist" or theoretical vs. practical you want to
get. Within the same module/class it may be acceptable to refer to
the instance variable vs. the method, especially where speed is
concerned.
>
> *****************************
>
> Reality Checking in 'C' code (as well as all of the 'C' language
derivatives, such as Objective-C) is accomplished with the assert()
macro. Brad Cox, the creator of Objective-C, recommends using
asserts (p. 98 and 99 of his book, Object-Oriented Programming, An
Evolutionary Approach, 2nd Edition) for Reality Checking (he calls it
something else, though) and clustering the checks into two groups:
(1) preconditions, and (2) postconditions. The advantage of using
assert() is that this debugging code can be turned off with a
compile-time switch.
>
> I don't entirely agree with this approach, for a couple of reasons:
>
> A precondition assert should verify that the argument values and/or
types are as they should be for the method to work properly.
Interestingly enough, except possibly with really obscure code (and I
can't even think of an example), the compiler and/or runtime system
will do this for you, so why do you need an assert for this case?
(Objective-C has a unique runtime system that almost no other
language has).
You might be able to gain a fuller appreciation for preconditions by
reading "Object Oriented Design" by Bertrand Meyer, which is where
Brad Cox picked up the notion of preconditions and postconditions.
There are several things that your discussion misses. A compiler can
check type information (is this an int, a const char*, the correct
object), but it cannot guarantee the condition of that argument (is
this int between values A and B, is the const char* a unique string,
is this object initialized to the proper state). Furthermore,
preconditions may extend to implicit arguments (global state, object
state), which also needs to be verified. For example; are we
currently printing? Is the associated nib for this object already
loaded.
Postconditions are treated in a similar fashion (the method operates
on state to produce a range of results; are the results in the
expected range?).
A third checking that is left out (I'll have to re-read Cox, as I
believe he misses this as well), is invarients. That is, what are
those states which may effect outcome which have nothing to do with
inputs. This includes environment conditions (memory, disk, threads,
etc), globals and some local state.
..
protocols are cool, but not supported outside NeXT :-(
>
> *****************************
> Methods must appear in both the implementation-module and
interface-module in the same order that they appear in standard NeXT
class documentation ...
Seeing as NeXT keeps tweaking their own definitions (witness 3.0
docs), and knowing some of the shortcomings (like delegate method
lookup) I'm not enamored with the suggestion. We break things into
logical groupings (existence, accessor, i/o, etc) within the header
and module files. This allows a programmer quick access to related
regions (which we deem pretty important). In fact, I'd wager you'll
encounter more production problems (i.e. bugs) by code that is spread
out alphabetically that clustered into logical groups.
--
Nevin Pratt, Digital Technology, Int'l Orem, Ut
NeXTmail preferred, but ONLY at my REAL email address:
nevin@dtint.dtint.com
-- NewsGrazer, a NeXTstep(tm) news reader, posting --
M>UQR=&8P7&%N<VE[7&9O;G1T8FQ<9C!<9G-W:7-S($AE;'9E=&EC83M<9C%<
M9FUO9&5R;B!#;W5R:65R.WT*7&UA<F=L,3(P"EQM87)G<C$R,`I[7&-O;&]R
M=&)L.UQR960P7&=R965N,%QB;'5E,#M]"EQP87)D7'1X-3(P7'1X,3`V,%QT
M>#$V,#!<='@R,3(P7'1X,C8V,%QT>#,R,#!<='@S-S(P7'1X-#(V,%QT>#0X
M,#!<='@U,S(P7&8P7&(P7&DP7'5L;F]N95QF<S(T7&9C,%QC9C`@26X@8V]M
M<"YS>7,N;F5X="YP<F]G<F%M;65R(&%R=&EC;&4@/#$Y.3).;W8Q-"XR,#,Y
M-30N,3DU,CA`9'1I;G0N=75C<#X@>6]U('=R;W1E.EP*/B!))VT@:&]P:6YG
M('1O('-T:6UU;&%T92!A(&QI=F5L>2!D:7-C=7-S:6]N(&]N('1H:7,N7`H^
M(%P*/B!))VQL('-T87)T(&]U="!W:71H(&UY(&]W;B!L:7-T+B`@5&5L;"!M
M92!W:&%T('EO=2!T:&EN:RXN+EP*/B!<"CX@0V]D:6YG(%)U;&5S(&%N9"!3
M=6=G97-T:6]N<R!F;W(@=&AE($YE6%1<"CX@8GD@3F5V:6X@4')A='1<"CX@
M;F5V:6Y`9'1I;G0N9'1I;G0N8V]M7`I<"EP*26YT97)E<W1I;F<@<W1U9F8@
M86YD(&$@;&]T(&]F(&=O;V0@<&]I;G0L('-O;64@;V8@=VAI8V@@96YD('5P
M(&)E:6YG(&%P<&QI8V%B;&4@;VYL>2!T;R!T:&4@3F585"!E;G9I<F]N;65N
M="X@0V]N<VED97(@=VAA="!K:6YD(&]F('!O<G1I;F<@<')O8FQE;7,@>6]U
M(&UA>2!R=6X@:6YT;R!I9B!Y;W4@:6UP;&5M96YT('EO=7(@<W1A;F1A<F1S
M+EP*7`I-;W)E('1H870@82!P87)T:6-U;&%R('-T86YD87)D+"!I="!P<F]B
M86)L>2!I<R!I;7!O<G1A;G0@9F]R(&$@9W)O=7`@;V8@<&5O<&QE('1O(&%G
M<F5E(&]N(&$@<W1A;F1A<F0@:6UP;&5M96YT871I;VXN(%1H:7,@:6YC;'5D
M97,@<W5B<')O:F5C="!S971U<"P@;V)J96-T(&YA;6EN9R!C;VYV96YT:6]N
M<RP@8V]D92!O=71L:6YI;F<L(&9I;&4@8V]M;65N=&EN9R!A;F0@;W)G86YI
M>F%T:6]N+"!M971H;V0O9G5N8W1I;VX@8V]M;65N=&EN9RP@;&EN92!O<B!C
M;'5S=&5R(&-O;6UE;G1I;F<L(&5T8RY<"EP*22=V92!B965N('1H92!R;W5T
M92!O9B!E>'1R96UE;'D@<W1R:6-T(&-O;G9E;G1I;VYS("AS964@0VAA<FQE
M<R!3>6UO;FDL($U)5"]-:6-R;W-O9G0@;VX@='EP92!N86UI;F<@8V%L8W5L
M=7,@8V]M;6]N;'D@<F5F97)R960@=&\@87,@(DAU;F=A<FEA;B(I+"!A;F0@
M22!F:6YD('1H92!M:61D;&4@9W)O=6YD(&UO<F4@87!P96%L:6YG("AI+F4N
M(&$@)W)E;&%X960G(&)U="!E;F9O<F-E86)L92P@9&5M;V-R871I8R!G<F]U
M<"!O9B!S=&%N9&%R9',I+EP*7`I<"@I<:5QL:34T,%QF8S%<8V8Q(#X@06QL
M('!A;F5L<R!A;F0@=VEN9&]W<R!S:&]U;&0@8F4@:6X@82!S97!A<F%T92!.
M24(@9FEL92P@;VYE('!E<B!.24(L('=I=&@@82!S97!A<F%T92!#;&%S<R!O
M8FIE8W0@=&\@8V]N=')O;"!A;F0@;6%N86=E(&5A8V@@3DE"+B`@1F]R(&5X
M86UP;&4L(&9O<B!T:&4@26YF;R!.24(@9FEL92P@=&AE<F4@<VAO=6QD(&%L
M<V\@8F4@9FEL97,@26YF;RYH(&%N9"!);F9O+FT@=&AA="!M86YA9V5S('1H
M92!.24(@9FEL92X@(%1H92!P86YE;"!O<B!W:6YD;W<@:6X@=&AE($Y)0B!F
M:6QE('-H;W5L9"!H879E('1H92!N86UE(&]F(&ET)W,@3DE"(&9I;&4@*&%N
M9"!A<W-O8VEA=&5D(&-L87-S(&9I;&5S*2!A<R!T:&4@;F%M92!O9B!T:&4@
M<&%N96PO=VEN9&]W("AT:&ES(&ES('-E=&%B;&4@=FEA('1H92!);G-P96-T
M;W(@<&%N96P@;V8@22Y"+M!))VT@=&%L:VEN9R!A8F]U="!T:&4@;F%M92!T
M:&%T('=I;&P@87!P96%R(&EN('1H92!T:71L92!B87(@;V8@=&AE('!A;F5L
M+W=I;F1O=RP@;F]T('1H92!N86UE(&%S(&ET(&UI9VAT(&%P<&5A<B!I;B!T
M:&4@(D]B:F5C=',B('!A<G0@;V8@=&AE($Y)0BDN7`H*7&DP7&QI,%QF8S!<
M8V8P(%P*5&AI<R!D;V5S;B=T(&%C8V]U;G0@9F]R('-U8BUP86YE;',@;W(@
M;6EC<F\M<&%N96P@;6%N86=E;65N="X@06QS;RP@:68@>6]U(&AA=F4@82!L
M87)G92!C;VQL96-T:6]N(&]F($Y)0G,@:70@;65A;G,@82!P<F]P86=A=&EO
M;B!O9B!O8FIE8W1S+V-L87-S97,N($%G86EN+"!A('-T86YD87)D(&UE=&AO
M9"!W:71H:6X@=&AE(&%P<&QI8V%T:6]N(&UA>2!B92!W:&%T)W,@<F5A;&QY
M(&-A;&QE9"!F;W(L(&YO="!A('-T86YD87)D(&%P<')O86-H('1O(&%L;"!A
M<'!L:6-A=&EO;G,N7`I<"CX@("`@7`H*7&E<;&DU-#!<9F,Q7&-F,2`^($]R
M+"!A="!T:&4@=F5R>2!L96%S="P@=&AE(&YA;64@;V8@=&AE($Y)0B!F:6QE
M("AA;F0@=&AE<F5F;W)E('1H92!A<W-O8VEA=&5D(&-L87-S(&9I;&5S*2!S
M:&]U;&0@8F4@;V)V:6]U<R!T;R!D971E<FUI;F4@<VEM<&QY(&)Y(&QO;VMI
M;F<@870@=&AE('!A;F5L("AO<B!W:6YD;W<I(&YA;64N("!);B!T:&ES('=A
M>2P@<VEM<&QY(')U;FYI;F<@=&AE('!R;V=R86T@=VEL;"!G:79E(&%N;W1H
M97(@<')O9W)A;6UE<B!A('9E<GD@9V]O9"!I9&5A(&]F('1H92!O8FIE8W0@
M<W1R=6-T=7)E(&]F('1H92!P<F]G<F%M+"!S:6YC92!H92!C86X@<&QA:6YL
M>2!S964@86QL(&]F('1H92!P86YE;',@86YD('=I;F1O=W,L(&%N9"!T:&5I
M<B!N86UE<RP@=VAI;&4@=&AE('!R;V=R86T@:7,@<G5N;FEN9RY<"@I<:3!<
M;&DP7&9C,%QC9C`@7`I!9V%I;BP@;6%N>2!N:6)S(&1O;B=T('-H;W<@=&ET
M;&5S+B!!;F]T:&5R("AP;W-S:6)L92D@8V]N<VED97)A=&EO;CH@:6YF;W)M
M871I;VX@:&ED:6YG+B!)9B!Y;W4@87)E(&1I<W1R:6)U=&EN9R!S;W5R8V4@
M9F]R('!U8FQI8R!C;VYS=6UP=&EO;B!T:&5N(&ES('!R;V)A8FQY(&YO="!W
M:&%T('EO=2!W86YT('1O(&1O+B!)9B!Y;W4@87)E('-E;&QI;F<@86X@87!P
M;&EC871I;VXL('EO=2!M87D@=VES:"!T;R!E;F-O9&4@<V]M92!T:&EN9W,N
M(%-O;64@=F5N9&5R<R!D;R!C;VYS:61E<B!I="!A<'!R;W!R:6%T92Y<"EP*
M/B`J*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*EP*/B!<"@I<:5QL:34T
M,%QF8S%<8V8Q(#X@5VAE;B!G:79E;B!A(&-H;VEC92!O9B!F97=E<B!O8FIE
M8W1S('1H870@9&\@;6]R92P@=F5R<W5S(&UO<F4@;V)J96-T<R!T:&%T(&%R
M92!S;6%L;&5R(&%N9"!D;R!L97-S+"!F879O<B!T:&4@=7-E(&]F('-M86QL
M97(@;V)J96-T<RX@(%EO=2=L;"!F:6YD('1H870@>6]U<B!O8FIE8W1S('=I
M;&P@9W)O=R!L87)G97(@9'5R:6YG(&1E=F5L;W!M96YT(&%N>7=A>2Y<"@I<
M:3!<;&DP7&9C,%QC9C`@7`I'96YE<F%L;'D@22=D(&%G<F5E+B!(;W=E=F5R
M+"!I9B!Y;W4G<F4@=&%L:VEN9R!A8F]U="!M86YA9VEN9R!S87DL(#$P,#`@
M8VQA<W-E<RP@>6]U)VQL(&9I;F0@82!C97)T86EN(')E9'5N9&%N8WD@<W1A
M<G1S('1O(&-R965P(&EN+B!/3U`@:6X@9V5N97)A;"!H87,@=&\@9&\@=VET
M:"!T:&4@;6%N86=E;65N="!O9B!I;F9O<FUA=&EO;BX@1&\@>6]U('=A;G0@
M=&\@;6%N86=E(&UO<F4@;W(@;&5S<R!T:&EN9W,@=VET:&EN(&$@9FEL93\@
M1&\@>6]U('=A;G0@=&\@;6%N86=E(&UO<F4@;W(@;&5S<R!T:&EN9W,@86UO
M;F<@9FEL97,_7`I<"E!E;W!L92!A<F4@<W1I;&P@96YA;6]R960@96YO=6=H
M('=I=&@@3T]0(&5N;W5G:"!T;R!N;W0@<V5E('1H92!S96-O;F0@<VET=6%T
M:6]N.B`@;V)J96-T<R!A;&QO=R!A(&5N8V%P<W5L:7IA=&EO;B!O9B!R96QA
M=&5D(&-O9&4@<V\@=V4@8V%N(&%V;VED('-I='5A=&EO;G,@;V8@=&EG:'1L
M>2!W<F%P<&5D(&-O9&EN9RX@3V)J96-T('-Y<W1E;7,@<W1I;&P@96YD('5P
M(&)E:6YG('1I9VAT;'D@8F]U;F0@86UO;F<@<V5T<R!O9B!O8FIE8W1S+B!/
M3U`@:&%S(&YO="`G<V]L=F5D)R!T:&4@<')O8FQE;2P@;VYL>2!P=7-H960@
M:70@9G5R=&AE<B!B86-K+"!A="!W:&EC:"!S=&%G92!T:&4@<')O8FQE;2!B
M96-O;65S(&5V96X@8FEG9V5R+B!#;VYS:61E<B!T:&4@:6UP86-T<R!O9B!F
M879O<FEN9R!S;6%L;&5R(&]B:F5C=',@=VAE;B!Y;W5R(&]B:F5C=',@8F5C
M;VUE(&EN=&5R9&5P96YD96YT(&%N9"!A8G5N9&%N="Y<"EP*22=M(&YE:71H
M97(@9F]R(&]R(&%G86EN<W0@;&%R9V4O<VUA;&P@;V)J96-T<SL@22=M(&9O
M<B!A<'!L>6EN9R!W:&%T(&)E<W0@<W5I=',@=&AE(&)I9R!P:6-T=7)E+EP*
M7`H^(%P*/B`J*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*EP*/B`)7`H*
M7&E<;&DU-#!<9F,Q7&-F,2`^($D@:&%V92!N;W0L(&%S('EE="P@<V5E;B!A
M('-I;F=L92!C;VYV:6YC:6YG('-I='5A=&EO;B!W:&5R92!P=6)L:6,@:6YS
M=&%N8V4@=F%R:6%B;&5S('=E<F4@;F5C97-S87)Y(&]R(&5V96X@9&5S:7)A
M8FQE+"!A;'1H;W5G:"!)(&%M(&AE<VET86YT('1O('-A>2!T:&%T('1H97)E
M(&%R92!N;VYE+B`N+BY<"@I<9F,P7&-F,"!5;FQE<W,@;W1H97)W:7-E(&-O
M;G9I;F-E9"!F;W(@<W!E8VEA;"!O8V-A<W-I;VYS+"!A;&P@:6YS=&%N8V4@
M=F%R:6%B;&5S('-H;W5L9"!O;FQY(&)E(&UO9&EF:6%B;&4@8GD@82!C;&%S
M<R!M971H;V0@*&DN92XL($Y/5"!B92!P=6)L:6,I+B`@270@<VAO=6QD(&%L
M<V\@;F]T(&)E(&UO9&EF:6%B;&4@8GD@;6]R92!T:&%N(&]N92!C;&%S<R!M
M971H;V0N7`H*7&DP7&QI,"!<"DET(&1E<&5N9',@;VX@:&]W(")P=7)I<W0B
M(&]R('1H96]R971I8V%L('9S+B!P<F%C=&EC86P@>6]U('=A;G0@=&\@9V5T
M+B!7:71H:6X@=&AE('-A;64@;6]D=6QE+V-L87-S(&ET(&UA>2!B92!A8V-E
M<'1A8FQE('1O(')E9F5R('1O('1H92!I;G-T86YC92!V87)I86)L92!V<RX@
M=&AE(&UE=&AO9"P@97-P96-I86QL>2!W:&5R92!S<&5E9"!I<R!C;VYC97)N
M960N7`I<"CX@(%P*/B`J*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*EP*
M/B`@("`@(%P*"EQI7&QI-30P7&9C,5QC9C$@/B!296%L:71Y($-H96-K:6YG
M(&EN("=#)R!C;V1E("AA<R!W96QL(&%S(&%L;"!O9B!T:&4@)T,G(&QA;F=U
M86=E(&1E<FEV871I=F5S+"!S=6-H(&%S($]B:F5C=&EV92U#*2!I<R!A8V-O
M;7!L:7-H960@=VET:"!T:&4@87-S97)T*"D@;6%C<F\N("!"<F%D($-O>"P@
M=&AE(&-R96%T;W(@;V8@3V)J96-T:79E+4,L(')E8V]M;65N9',@=7-I;F<@
M87-S97)T<R`H<"X@.3@@86YD(#DY(&]F(&AI<R!B;V]K+"!/8FIE8W0M3W)I
M96YT960@4')O9W)A;6UI;F<L($%N($5V;VQU=&EO;F%R>2!!<'!R;V%C:"P@
M,FYD($5D:71I;VXI(&9O<B!296%L:71Y($-H96-K:6YG("AH92!C86QL<R!I
M="!S;VUE=&AI;F<@96QS92P@=&AO=6=H*2!A;F0@8VQU<W1E<FEN9R!T:&4@
M8VAE8VMS(&EN=&\@='=O(&=R;W5P<SH@*#$I('!R96-O;F1I=&EO;G,L(&%N
M9"`H,BD@<&]S=&-O;F1I=&EO;G,N("!4:&4@861V86YT86=E(&]F('5S:6YG
M(&%S<V5R="@I(&ES('1H870@=&AI<R!D96)U9V=I;F<@8V]D92!C86X@8F4@
M='5R;F5D(&]F9B!W:71H(&$@8V]M<&EL92UT:6UE('-W:71C:"Y<"@I<:3!<
M;&DP7&9C,%QC9C`@/B!<"CX@22!D;VXG="!E;G1I<F5L>2!A9W)E92!W:71H
M('1H:7,@87!P<F]A8V@L(&9O<B!A(&-O=7!L92!O9B!R96%S;VYS.EP*/B`@
M("!<"CX@02!P<F5C;VYD:71I;VX@87-S97)T('-H;W5L9"!V97)I9GD@=&AA
M="!T:&4@87)G=6UE;G0@=F%L=65S(&%N9"]O<B!T>7!E<R!A<F4@87,@=&AE
M>2!S:&]U;&0@8F4@9F]R('1H92!M971H;V0@=&\@=V]R:R!P<F]P97)L>2X@
M($EN=&5R97-T:6YG;'D@96YO=6=H+"!E>&-E<'0@<&]S<VEB;'D@=VET:"!R
M96%L;'D@;V)S8W5R92!C;V1E("AA;F0@22!C86XG="!E=F5N('1H:6YK(&]F
M(&%N(&5X86UP;&4I+"!T:&4@8V]M<&EL97(@86YD+V]R(')U;G1I;64@<WES
M=&5M('=I;&P@9&\@=&AI<R!F;W(@>6]U+"!S;R!W:'D@9&\@>6]U(&YE960@
M86X@87-S97)T(&9O<B!T:&ES(&-A<V4_("`H3V)J96-T:79E+4,@:&%S(&$@
M=6YI<75E(')U;G1I;64@<WES=&5M('1H870@86QM;W-T(&YO(&]T:&5R(&QA
M;F=U86=E(&AA<RDN7`I<"EEO=2!M:6=H="!B92!A8FQE('1O(&=A:6X@82!F
M=6QL97(@87!P<F5C:6%T:6]N(&9O<B!P<F5C;VYD:71I;VYS(&)Y(')E861I
M;F<@(D]B:F5C="!/<FEE;G1E9"!$97-I9VXB(&)Y($)E<G1R86YD($UE>65R
M+"!W:&EC:"!I<R!W:&5R92!"<F%D($-O>"!P:6-K960@=7`@=&AE(&YO=&EO
M;B!O9B!P<F5C;VYD:71I;VYS(&%N9"!P;W-T8V]N9&ET:6]N<RY<"EP*5&AE
M<F4@87)E('-E=F5R86P@=&AI;F=S('1H870@>6]U<B!D:7-C=7-S:6]N(&UI
M<W-E<RX@02!C;VUP:6QE<B!C86X@8VAE8VL@='EP92!I;F9O<FUA=&EO;B`H
M:7,@=&AI<R!A;B!I;G0L(&$@8V]N<W0@8VAA<BHL('1H92!C;W)R96-T(&]B
M:F5C="DL(&)U="!I="!C86YN;W0@9W5A<F%N=&5E('1H92!C;VYD:71I;VX@
M;V8@=&AA="!A<F=U;65N="`H:7,@=&AI<R!I;G0@8F5T=V5E;B!V86QU97,@
M02!A;F0@0BP@:7,@=&AE(&-O;G-T(&-H87(J(&$@=6YI<75E('-T<FEN9RP@
M:7,@=&AI<R!O8FIE8W0@:6YI=&EA;&EZ960@=&\@=&AE('!R;W!E<B!S=&%T
M92DN($9U<G1H97)M;W)E+"!P<F5C;VYD:71I;VYS(&UA>2!E>'1E;F0@=&\@
M:6UP;&EC:70@87)G=6UE;G1S("AG;&]B86P@<W1A=&4L(&]B:F5C="!S=&%T
M92DL('=H:6-H(&%L<V\@;F5E9',@=&\@8F4@=F5R:69I960N($9O<B!E>&%M
M<&QE.R!A<F4@=V4@8W5R<F5N=&QY('!R:6YT:6YG/R!)<R!T:&4@87-S;V-I
M871E9"!N:6(@9F]R('1H:7,@;V)J96-T(&%L<F5A9'D@;&]A9&5D+EP*7`I0
M;W-T8V]N9&ET:6]N<R!A<F4@=')E871E9"!I;B!A('-I;6EL87(@9F%S:&EO
M;B`H=&AE(&UE=&AO9"!O<&5R871E<R!O;B!S=&%T92!T;R!P<F]D=6-E(&$@
M<F%N9V4@;V8@<F5S=6QT<SL@87)E('1H92!R97-U;'1S(&EN('1H92!E>'!E
M8W1E9"!R86YG93\I+EP*7`I!('1H:7)D(&-H96-K:6YG('1H870@:7,@;&5F
M="!O=70@*$DG;&P@:&%V92!T;R!R92UR96%D($-O>"P@87,@22!B96QI979E
M(&AE(&UI<W-E<R!T:&ES(&%S('=E;&PI+"!I<R!I;G9A<FEE;G1S+B!4:&%T
M(&ES+"!W:&%T(&%R92!T:&]S92!S=&%T97,@=VAI8V@@;6%Y(&5F9F5C="!O
M=71C;VUE('=H:6-H(&AA=F4@;F]T:&EN9R!T;R!D;R!W:71H(&EN<'5T<RX@
M5&AI<R!I;F-L=61E<R!E;G9I<F]N;65N="!C;VYD:71I;VYS("AM96UO<GDL
M(&1I<VLL('1H<F5A9',L(&5T8RDL(&=L;V)A;',@86YD('-O;64@;&]C86P@
M<W1A=&4N7`I<"BXN+EP*7`IP<F]T;V-O;',@87)E(&-O;VPL(&)U="!N;W0@
M<W5P<&]R=&5D(&]U='-I9&4@3F585"`Z+2A<"EP*/B`@7`H^("HJ*BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ7`H*7&E<;&DU-#!<9F,Q7&-F,2`^($UE
M=&AO9',@;75S="!A<'!E87(@:6X@8F]T:"!T:&4@:6UP;&5M96YT871I;VXM
M;6]D=6QE(&%N9"!I;G1E<F9A8V4M;6]D=6QE(&EN('1H92!S86UE(&]R9&5R
M('1H870@=&AE>2!A<'!E87(@:6X@<W1A;F1A<F0@3F585"!C;&%S<R!D;V-U
M;65N=&%T:6]N("XN+EP*"EQI,%QL:3!<9F,P7&-F,"!<"E-E96EN9R!A<R!.
M95A4(&ME97!S('1W96%K:6YG('1H96ER(&]W;B!D969I;FET:6]N<R`H=VET
M;F5S<R`S+C`@9&]C<RDL(&%N9"!K;F]W:6YG('-O;64@;V8@=&AE('-H;W)T
M8V]M:6YG<R`H;&EK92!D96QE9V%T92!M971H;V0@;&]O:W5P*2!))VT@;F]T
M(&5N86UO<F5D('=I=&@@=&AE('-U9V=E<W1I;VXN(%=E(&)R96%K('1H:6YG
M<R!I;G1O(&QO9VEC86P@9W)O=7!I;F=S("AE>&ES=&5N8V4L(&%C8V5S<V]R
M+"!I+V\L(&5T8RD@=VET:&EN('1H92!H96%D97(@86YD(&UO9'5L92!F:6QE
M<RX@5&AI<R!A;&QO=W,@82!P<F]G<F%M;65R('%U:6-K(&%C8V5S<R!T;R!R
M96QA=&5D(')E9VEO;G,@*'=H:6-H('=E(&1E96T@<')E='1Y(&EM<&]R=&%N
M="DN($EN(&9A8W0L($DG9"!W86=E<B!Y;W4G;&P@96YC;W5N=&5R(&UO<F4@
M<')O9'5C=&EO;B!P<F]B;&5M<R`H:2YE+B!B=6=S*2!B>2!C;V1E('1H870@
M:7,@<W!R96%D(&]U="!A;'!H86)E=&EC86QL>2!T:&%T(&-L=7-T97)E9"!I
M;G1O(&QO9VEC86P@9W)O=7!S+EP*7`H*7'!A<F1<='@Q,34R7'1X,C,P-%QT
M>#,T-39<='@T-C`X7'1X-3<V,%QT>#8Y,3)<='@X,#8T7'1X.3(Q-EQT>#$P
M,S8X7'1X,3$U,C!<9C%<9F,P7&-F,"!<"BTM7`I.979I;B!0<F%T="P@1&EG
M:71A;"!496-H;F]L;V=Y+"!);G0G;"`@("!/<F5M+"!5=%P*3F585&UA:6P@
M<')E9F5R<F5D+"!B=70@3TY,62!A="!M>2!214%,(&5M86EL(&%D9')E<W,Z
=(&YE=FEN0&1T:6YT+F1T:6YT+F-O;5P*7`H*?0I,
`
--
---
root root@dtint.dtint.com
Digital Technology Int. (801)226-2984
500 W. 1200 South, Orem UT, 84057 FAX (801) 226-8438
Re: Coding Rules/Suggestions
Author: Steven T. Abell
Date: Thu, 19 Nov 1992 08:28
Date: Thu, 19 Nov 1992 08:28
35 lines
2063 bytes
2063 bytes
nevin@dtint.dtint.com writes: >I've been the route of extremely strict conventions (see Charles >Symoni, MIT/Microsoft on type naming calculus commonly referred to as >"Hungarian"), and I find the middle ground more appealing (i.e. a >'relaxed' but enforceable, democratic group of standards). I use a Hungarian style similar to Symoni's. It was forced upon me against my will a few years back. Now, it seems to me to be a necessity. There are several concrete advantages, some of which are: 1) Simpler semantics checking. You rely a *lot* less on your memory of what kind of thing a variable represents. Multi-level pointers become tractable. Mismatches between declaration and usage are visually apparent. Related entities are clearly related by similarity of names. 2) Uniformity across a project. People tend to choose the same names for the same things, even when they aren't communicating. 3) Name formation becomes much more mechanical. You can stop spending all day looking for good names for your variables, and expend your creativity in more valuable ways. 4) Simpler, more reliable global search-and-replace. With the right set of naming rules, you can make some really scary name changes safely, and not take all day to do it. 5) Code from code generators is more easily read by humans. One of the greatest advances of the Industrial Revolutions was the idea of standardized, interchangeable parts. Object programming does this at a high level, Hungarian does it at a low level. Both matter. If anybody out there hasn't seen this stuff and is interested, send e-mail. Steve abell@netcom.com
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads