🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.next.programmer
Article #1814

Re: Coding Rules/Suggestions (RTF)

#1814
From: nevin
Date: Wed, 18 Nov 1992 21:13
360 lines
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
Technical Details
Message-ID: <1992Nov18.211313.25652@dtint.uucp>
Path: arc1-ca.pugleaf.net!sparky!uunet!dtint!usenet

Show Full Headers
Complete Article Headers
Newsgroups: comp.sys.next.programmer
Path: arc1-ca.pugleaf.net!sparky!uunet!dtint!usenet
From: nevin@dtint.dtint.com
Subject: Re: Coding Rules/Suggestions (RTF)
Message-ID: <1992Nov18.211313.25652@dtint.uucp>
Sender: usenet@dtint.uucp
Reply-To: nevin@dtint.dtint.com
Organization: Digital Technology, International
Date: Wed, 18 Nov 92 21:13:13 GMT
Lines: 360