It's better to write clear, legible code that saves a human minutes of reading, than complex code that might save a computer a few milliseconds of processing time per year, because human time costs more than machine time.
Also the clear code will result in fewer misinterpretations, which will mean fewer bugs (especially when the original author is not the one doing maintenance years later), further reducing costs in dollars, man hours, and frustration.
First off, !ptr is easy to read for any C coder. In addition, in an embedded system, speed and/or size may matter more.
But with that said, I agree with you on general systems. In this day and age, even for MOST embedded systems, memory and cpu power is cheap enough, that code maintence becomes a costly issue.
!ptr was his example of a simple case. I wasn't saying it's too complex to read. But
if (ptr == 0)
does look "cleaner". And as somebody mentioned above
if (0 == ptr)
looks cleaner and makes equality test versus assignment operator errors show up at compile time.
I was also speaking in terms of non-embedded systems, where storage and CPU time are plentiful. In an embedded or real-time environment, it might be more cost effective to tweak the code.
And it is also true that simple code is easier to optimize automatically and programming induced optimization can prevent the compiler from doing the best job of optimization.
Trouble is that "clear" may be misleading. For example, "if(ptr==NULL)" expresses a certain intent of the programmer (compare a variable against the null pointer), but that is not actually quite what that statement means. Many C programmers avoid "if(ptr==NULL)" because it is actually kind of obscure.
It's better to write clear, legible code that saves a human minutes of reading, than complex code that might save a computer a few milliseconds of processing time per year, because human time costs more than machine time.
Also the clear code will result in fewer misinterpretations, which will mean fewer bugs (especially when the original author is not the one doing maintenance years later), further reducing costs in dollars, man hours, and frustration.
You raise a good point, but one thing to remember is
I have the simplest tastes. I am always satisfied with the best.
-- Oscar Wilde
Clear & Concise Code (Score:5, Interesting)
Also the clear code will result in fewer misinterpretations, which will mean fewer bugs (especially when the original author is not the one doing maintenance years later), further reducing costs in dollars, man hours, and frustration.
Yes and No (Score:2)
But with that said, I agree with you on general systems. In this day and age, even for MOST embedded systems, memory and cpu power is cheap enough, that code maintence becomes a costly issue.
Re:Yes and No (Score:2)
does look "cleaner". And as somebody mentioned above
looks cleaner and makes equality test versus assignment operator errors show up at compile time.
I was also speaking in terms of non-embedded systems, where storage and CPU time are plentiful. In an embedded or real-time environment, it might be more cost effective to tweak the code.
Re:Clear & Concise Code (Score:1)
Re:Clear & Concise Code (Score:2)
So clear simple code can have two benefits.
but what's "clear"? (Score:2)
Re:Clear & Concise Code (Score:2)
Re:Clear & Concise Code (Score:2)
Remember that your program can have many more users than programmers, and their time is worth something too.
Re:Clear & Concise Code (Score:1)
It's better to write clear, legible code that saves a human minutes of reading, than complex code that might save a computer a few milliseconds of processing time per year, because human time costs more than machine time. Also the clear code will result in fewer misinterpretations, which will mean fewer bugs (especially when the original author is not the one doing maintenance years later), further reducing costs in dollars, man hours, and frustration.
You raise a good point, but one thing to remember is