gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFA]: BOOL coding standards (Was: Problemwith+numberWithBool:?)


From: Kazunobu Kuriyama
Subject: Re: [RFA]: BOOL coding standards (Was: Problemwith+numberWithBool:?)
Date: Tue, 10 Feb 2004 16:19:35 +0900
User-agent: Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1

Pascal J.Bourguignon wrote:

Kazunobu Kuriyama writes:

So I'm wondering if changing the expression to
[NSNumber numberWithBool: isYES(i=256)];
or something like this always gives the right answer. Sometimes it is, but
what if generating NO is the coder's genuine intention?


Then it was obscure code. He should have made his intention explicit
and he shoudl have written:

[NSNumber numberWithBool: (((i=256)&0xff)!=0)]

confident that the compiler would have generated EXACTLY the same code
(at least with -O3).

I think one of the present problems is to answer the question whether or
not the proposed macro can correctly fix such existing code (without
any unexpected cost if possible), not to give the code an ethical/aesthetic
evaluation.

Although I'm saying we should take C syntax into consideration more, I'm
never advocating any obfuscating C at all.  So I don't think one should
write (i=256)&0xff != 0 for the purpose.

If we have to pay attention to semantics defined by ourselves as well as
syntax, I'm afraid it makes the maintenance of code harder because we have to take two possible interpretations into consideration and decide which is the coder's intention. Furthermore, it unexpectedly reduces the readability
of code when semantics and syntax respectively give contradictory
interpretations.


In any case,

[NSNumber numberWithBool: i=256]

is much less readable than:

[NSNumber numberWithBool: (((i=256)&0xff)!=0)]

which itself is much less readable than:

i=256;
[NSNumber numberWithBool: NO]

(Here you see another "stylistic" rule in my book: never use
assignation in expressions, only in statements, and one at a time);

I was not talking about this sort of readability, or readability for
human being.  What I meant was whether or not a given expression yields
a consistent interpretation to which both we and compilers can agree.
If the syntax-based interpretation of some code differs from the
corresponding sematics-based one, we can call the code unreadable as
well.

We human being read code primirily based on semantics, but our poor
compilers do it only relying on syntax (or, they don't know any other
way).  This discrepancy is just what I'm worrying about.  IOW, introducing
user-defined semantics that compilers don't exactly know is dangerous;
therefore, we should be prudent in doing it.

Cheers,
- Kazunobu Kuriyama





reply via email to

[Prev in Thread] Current Thread [Next in Thread]