gnustep-dev
[Top][All Lists]
Advanced

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

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


From: Nicola Pero
Subject: Re[2]: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?)
Date: Fri, 30 Jan 2004 19:26:19 +0000 (GMT)

>  >| I don't have particular objections to change 'if ([this canDoThat] ==
>  >| YES)' into 'if ([this canDoThat])', if we write clearly in the coding
>  >| standards that this can be done only for methods returning a BOOL, and
>  >| that everything else (pointers, integers, etc) must be compared against
>  >| something.  So whenever you'd see 'if ([this doThat])' you know that the
>  >| result type must have been a BOOL since it's compared to nothing.
> 
> I think that 
>         if (MyPtr)
> is more readable than
>         if (MyPtr == NULL)
> because it's shorter and still easily understandable buts it's only my 
> opinion :-)

I see your point and I somewhat respect it, but I'd politely disagree with
you.

Shorter code is not necessarily more readable.  Variables are often
declared somewhere else, and variable names often don't help that much.  
Not all pointers are called 'xxxPtr'.  For example,

 if (bytes)
   {
   }

is a typical example of obscure code.  What is 'bytes' ?  Is it an integer
?  A char * ?  an object ?

I think I really prefer 

 if (bytes > 0)
   {
   }

then it's clear that bytes is a counter, and that is executed only if the 
counter is positive.

 if (bytes != NULL)
   {
   }

then it's clear that bytes is a C pointer, likely a C buffer, and the code
is executed is the pointer points to something (which usually means you 
can derefence it).

  if (bytes != nil)
    {
    }

then it's clear that bytes is an ObjC object, likely an NSData * object,
or maybe an NSString *, and the code is executed if the object is not nil
(which usually means you can send messages to it).

Those cases are very different, and I like the code to immediately give a
feeling of which case you're in - the code is more expressive and easier
to read then.






reply via email to

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