Re: Re[2]: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?)

[Nicola Pero]

> >  if (bytes)
> >    {
> >    }
> > is a typical example of obscure code.  What is 'bytes' ?  Is it an 
> > integer
> > ?  A char * ?  an object ?
> 
> I don't find it that obscure. Its a descriptive name, in which case 
> could a 'bytes' name imply an integer? That would be byteCount or 
> numberOfBytes or something like that, but 'bytes' is just that - an 
> array of bytes.

The problem with coding conventions is that people often don't follow
them.  I've seen the name 'bytes' used to mean almost anything you can
think of.  I don't think it's a strange example.

Sure variable names should be chosen carefully, but I prefer to have
redundant coding conventions - having both well chosen names, and very
readable and explicit conditions.

It's a personal preference.  I'd rather have code which is over readable
than code which is unreadable.  I've seen enough of that.

Readable code is never clever in a way which is obscure and requires
thinking.  Readable code is just readable and explicit, you don't need to
think to read and understand it - readable code is almost pseudo-English.  
The advantage being you can read and check a lot of it quickly.

I think readable code says "if (condition)" where condition is a condition
clearly expressed, almost in English.

If condition is a method call returning a boolean, or a boolean variable,
I'm happy with using "if (condition)".  In all other cases when a variable
is checked, I prefer to see written down what it is checked against.

if (a != NULL)
if (a == NULL)
if (a == nil)
if (a != nil)
if (a > 0)
if (a == 0)
if (a < 0)
if (...)

I find all this stuff very readable, much more readable than 'if (a)' or
'if (!a)' when a is a pointer or integer, and comparing against NULL or
nil is not error-prone and I actually believe it to be correct C - more
correct that 'if (pointer)'.  And it's actually what you are doing, you
are following that branch if a is not the nil object, or if a is not the
NULL pointer.  That's exactly the explanation you'd give to a newbie of 
the condition, and that's exactly how I like it to be written. :-)


About booleans, that's the part where I'm personally more uncertain :-)

It seems a reasonable convention to use 'if (condition)' and 'if (!  
condition)'.  That's logical, and it's supposed to be readable.

So I vote for that.

But let me chat/rant a little about this since we are talking about it.

if (condition) is fine.  But in my experience in reading quickly pages and
pages of (my own and other's) code, when I find

if (! [self supportsMMS])
  {
  }

(negation of a boolean condition) I always feel my mental parser slows
down, elaborates half a second, then goes on.  I can parse 'if (self !=
nil)' and 'if ([self supportsMMS])' much faster than this; it probably has
to do with the fact that in the natural language I'd say/think

if self does NOT supportMMS

and I find it difficult to read the negative conditional because it is 
expressed as -

if NOT (self supportsMMS)

which requires processing to be converted back into the natural form.  I
wish there was a syntax fox moving the NOT inside the method call. :-)

The other thing is that often methods are badly named, or just return
booleans for operations with some convention you have to know, so you can
easily end up having

if (! [self processData: data])

and when I read that I can feel that it requires me a fraction of a second
of additional thinking, as you then have to actually think why/what
happens when -processData: returns YES, and why/what happens when it
returns NO, and which of the two cases is covered by the condition.

In such cases, I often get the feeling that

if ([self processData: data] == NO)

can be a lot more readable, because the boolean returned by the method is
not really a "condition", but it's more like a return value, and this
immediately tells you that if the return value is NO, the branch is
executed.  It's like explicitly writing down in a braindead simple way
when the branch is executed - of course it adds nothing, but it saves a
few cpu cycles in my head when I reread the code.

Maybe in those cases the method should have a different name ?

Anyway as I said I'm happy about writing 'if (! [self processData:  
data])' instead of 'if ([self processData: data] == NO)'.  Maybe other
people find it very readable, readability is subjective.