1237cf1b52d5
c_echo



Hello Bo - 

--8<--cut 

CA>> Not sure but I think there is some misunderstanding going
CA>> on here. 

BS> Hm.. I'm not sure. 

Nor am I. 

CA>> Both you and Roy are including code within paragraphs of
CA>> English that obscures the meaning(s). 

CA>> You have "if(function(parm)) ?" in your text - the "?"
CA>> happens to have a 'meaning' within the C language that I
CA>> don't think you intended to refer to. 

BS> It was a question :-) Maybe i should put brackets around it. 

Typically lines of 'code' are separate from paragraphs of text.
It's much easier to read and undertand that way with fewer
misunderstandings. 

CA>> Roy has "#define FALSE 0 and TRUE !FALSE" within his text
CA>> and I think Roy _meant_: 

CA>> #define FALSE 0 

CA>> #define TRUE !FALSE 

BS> So far i'm on. 

CA>> The "and" appears to be pseudo code as it is within the
CA>> text minus another "#define" statement. 

CA>> Generally it is best to keep the lines of code separate in
CA>> messages rather than included within a paragraph. It is
CA>> too easy for the meaning of a particular line of code to
CA>> be misunderstood when the end of the code line is not
CA>> obvious? 

BS> Well look at that example, my code: 

BS> #define FALSE 0 

BS> #define TRUE !FALSE 

BS> if(func(parm) == TRUE) ... 

BS> then after complication it would be: 

BS> if(func(parm) == !FALSE) ... 

BS> Or? 

I'm not saying either would not be functional but there are
programmers who prefer that the source code is self-documenting
as well as functional. Combining too much into one line of code
can make it difficult for others to comprehend why it was
constructed in that particular fashion. 

>
>        ,                          ,
>      o/      Charles.Angelich      \o       ,
>       __o/
>     / >          USA, MI           < \   __\__
 

___ * ATP/16bit 2.31 * 
... DOS the Ghost in the Machine! http://www.undercoverdesign.com/dosghost/

--- Maximus/2 3.01