NULL not defined?

[Solar]

@ RetainSoft:

We certainly have very different views on readability.

Compare:

Code: Select all

if ( pointer == NULL )
if ( pointer != NULL )
if ( !pointer )
if ( pointer )

I challenge your claim that #3 and #4 are as easily readable as the former two.

And if you do the [tt]if ( NULL == pointer )[/tt] thing in a project we both work on (and I have a saying in), you will die. In interesting ways. Over a period. (To quote Terry Pratchet. )

You seriously suggest adopting an unintuitive, backward coding style that is hard to read to catch a possible error source that is perfectly handled by [tt]-Wall -Werror[/tt]?

Code: Select all

test.c:4: warning: suggest parentheses around assignment used as truth value

[RetainSoftware]

the -Wall -Werror is indeed a nice solution to find the asignment comparison problem and are also the compiler flags i've enabled in GCC but not all compilers support these options, though the list is getting shorter by the day. A few years ago even Visual Studio didn't complain about this, set by a specific company profile :'(. The "unintuitive, backward coding style" solved this problem. Though i though it was clear i don't use the NULL comparison all together only for other constants/defines.

As to the readabilty of the pointer i guess it's a difference in how you read the code. The ! is specified as the NOT operator and the line if(!pointer) would be read as if(NOT a pointer) as the if(pointer == NULL) would be read as if(pointer is equal to NULL) raising the question what if pointer is a pointer to an object? Is NULL then also an pointer to an object because to be intuitive and correct i need to compare apples with apples. So for me the #3 and #4 are clearer then the other two.

Now i'm very interested in your view on why they are more readable and maybe you're answer will convert me to your way of thinking.

[Candy]

Now i'm very interested in your view on why they are more readable and maybe you're answer will convert me to your way of thinking.

Try this:

Code: Select all

char *memory = (char *)malloc(4096);
if (!memory) exit(2);

"If there's no memory there then exit." That's more intuitive than "If the memory pointer equals NULL then exit." Same for objects, don't call your object an unintuitive "pointer" but something like "apple" for an Apple *:

Code: Select all

Apple *apple = getApple();
if (apple) {
  // apple-ish thing
} else {
  // no apple
}

[Solar]

Now i'm very interested in your view on why they are more readable and maybe you're answer will convert me to your way of thinking.

Much simpler than any semantics of "NOT pointer" vs. "pointer not equal NULL", and threefold:

- the single bang ('!') is easier overlooked than == or !=;
- pedantic nitpicker that I am, I prefer to be type-correct, and [tt]if ( pointer )[/tt] isn't;
- the standard functions in question are specified to return NULL, so some lazy braincell in my skull refuses to test the return value against something else.

I know that #2 and #3 are a bit anal, so I'll lean heavily on #1.

[RetainSoftware]

@candy
hmm... i fail to see your point. I see two examples i think make perfectly sense both applying rule #3 and #4, though i would prefix the variable names with p or ptr and use only rule #3.

as i understand you like to have

Code: Select all

Apple *ptr_apple = getApple();
if (ptr_apple != NULL) {
  // apple-ish thing
} else {
  // no apple
}

as to my

Code: Select all

Apple *ptr_apple = getApple();
if (!ptr_apple) {
  // no apple
} else {
  // apple-ish thing
}

so why do you find your solution more clear?

@solar

- the single bang ('!') is easier overlooked than == or !=

That's why syntax-highlighting is very handy

- pedantic nitpicker that I am, I prefer to be type-correct, and if ( pointer ) isn't

true, however what is the type of NULL. Therefore i think the type-correctness doesn't hold and semantics take over.

- the standard functions in question are specified to return NULL, so some lazy braincell in my skull refuses to test the return value against something else.

hmm, some of my braincells also have problems with this..

[distantvoices]

Althou this is not a thread of my concern, I have to add a line or two:

@Solar: You do like uttering ugly threats, eh? Lucky you that you've mentioned terry Pratchett whose books I'm not only reading. I 'm devouring them. *fg* But, despite all the fun in using such sentences, in real life I'd jump to my feet rather quickly if someone - even if he were someone who (thinks he) has a say - uttered such stuff to me. And then, that lad 'd live in very interresting times.

The discussion is insofar void in my opinion as each programmer develops his own preferred way to test conditions. While one may think

Code: Select all

if(pointer){blah}

is readable, others prefer

Code: Select all

if(pointer!=NULL){blah}

Internally, it comes down to the same assembly nitty gritty.

Of course in projects where more ppl are working together, one should negotiate/communicate a coding style beforehands and not nitpick on the potetial wrong goer afterwards.

[Solar]

@ BI:

Don't worry about me uttering colorful death threats. If I mean it, I don't threaten, I kill quickly and silently. ;D

(Note the smiley, man! The co-developer sitting right in front of me uses the same backwards notation, and all I do to him is uttering colorful death threats. ;D )

That's why syntax-highlighting is very handy.

So you rely on the syntax highlighting of your source editor, but not the diagnostics of your compiler?

- pedantic nitpicker that I am, I prefer to be type-correct, and if ( pointer ) isn't

true, however what is the type of NULL.

It doesn't really matter, see? If [tt]malloc()[/tt] fails, it returns NULL. Comparing the return code of [tt]malloc()[/tt] with NULL evaluates to a boolean value.

What is the type of a negated void pointer?

In the end, it's aesthetics. It's like the one true brace style. (Which, of course, is the ANSI style. )

[distantvoices]

@solar: well, I have noted it. Hows the saying? The dog that barks bites not? (doesn't bite <-- That's me being told to write correctly by my buildt in langenscheidt dictionary)

the aesthetics stuff is too true. See, while I prefer to use

Code: Select all

int blah(int one,int two){
 ...stuff...;
}

the standard says this:

Code: Select all

int blah(int one,int two)
{
    ...stuff...;
}

Which I find ugly. Too deep indentation doesn't fease readability for me. I'm used to two spaces indent (that's from my times developing on BS2000/edt & cobol. If you know cobol, you know
what I mean...)

But after all, if we can agree, I'll state that for a project a common coding style should be negotiated and followed thereafter by every project member.

stay safe.

[Solar]

But after all, if we can agree, I'll state that for a project a common coding style should be negotiated and followed thereafter by every project member.

Doesn't work. To be really precise, you end up with 10-20 pages of legalese. About the only really working solution is deciding on a configuration for a source reformatter run automatically before code is checked in.

Too bad there isn't a really functional C++ reformatter.

[zloba]

- the single bang ('!') is easier overlooked than == or !=;

by the same token, all integers must be compared with 0, and booleans with true/false?

i never once experienced the problem of overlooking the negation. and everything else being equal, the less mundane typing there is, the easier it is to concentrate on code.

but it's all a matter of preferences.

for a project a common coding style should be negotiated and followed thereafter by every project member

as long as you don't go crazy over it, instead of things that actually matter, like actual code.

[Candy]

the standard says this:

Code: Select all

int blah(int one,int two)
{
    ...stuff...;
}

The ISO standard, the ANSI standard or the K&R standard? If you want to go nitty-gritty, go for K&R in all your code:

Code: Select all

int blah(one, two) 
int one, two;
{
    ...stuff...;
}

I tend to prefer short notations that save space and allow me to view as much code as possible in a given amount of space, whilst not making ambiguous views (multiple statements in one line etc). Implicitly checking against null could be seen as checking whether there is a pointer or not, which makes the ! notation clear. If you don't see single-char differences in source code you probably shouldn't have been programming. Using assignments in if statements makes for ambiguous statements, so do those only when entirely ascertained and when you can still read the line as a single line. Stuff like if((bytes_read = read()) <> 0) {... is readable as "if you read more than 0 bytes then".

Same complaint with the if () \n { logic. That would be similar to stuff like:

if you can read a book
then
do something
end if

All languages that have a "then" keyword expect it to appear after the if, since it's implicitly coupled with the if.


My personal conclusion: if you can read (your) code like a book, you'll understand it quite a lot quicker. Write your code like you're writing a novel or a manual.

PS: that also goes for typo's or language mistakes in variable names... don't do them... use either very short names or descriptive and correct names...

[Solar]

- the single bang ('!') is easier overlooked than == or !=;

by the same token, all integers must be compared with 0, and booleans with true/false?

Indeed I test integers against 0 explicitly. But booleans already are booleans, which is the expected type for a conditional.

i never once experienced the problem of overlooking the negation.

I would probably lie if I said I never experienced it, but I didn't experience it often. As I said, it's aquestion of style and aesthetics, and thus there is no final truth.

...and everything else being equal, the less mundane typing there is, the easier it is to concentrate on code.

I know that POV. But code is written only once, but read and modified many, many times. I prefer code that is explicit, verbose, and has lots of comments, as this helps me 90% of the time while having little to type only helps me the rest of the time. (And I'm a pretty quick typist.)

...but it's all a matter of preferences.

ACK.

[distantvoices]

@solar: ah. coders are lazy typers. Besides it works. There needs to be one who has the final say. You should know, what I mean, eh? Apropos, as we're talking of it: I sometimes use a very explicit coding style, so I know afterwards what happens there. *gg*

@candy: Ach, K&R is soooo ancient that there is dust falling from my eyelashes after having read you mentioning that Standard. Minix sourcecode is full of it. *chuckle*

[Solar]

@solar: ah. coders are lazy typers.

Yes, coders are lazy typers. Maintenance coders tend to revise that standpoint after a couple of years of digging through uncommented code that looks as if it's been through a RLE compression.

[Candy]

<empty reply since I'm a maintenance coder now and I have nothing to add... except the hollow feeling of a hack that nobody ever documented, with a dozen smaller hacks on top of it that weren't documented either...>