Re: Coding style for conditionals
On Apr 8, 8:33 am, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
gwowen <gwo...@gmail.com> writes:
You probably don't recall having misread them, because you've rarely
seen third-party code that uses them.
I thought to have seen this often in the C code I used to read.
The following looks very natural and idiomatic to me:
if( f = fopen( ... ))...
if( m = malloc( ... ))...
Actually, those ones I do see, although usually in the negation:
if((f=fopen(...) == NULL){
// handle error
}
I'll accept those as exceptions, though because (i) fopen() and
malloc() are incredibly common, and everyone can be expected to know
how the signal failure (ii) FILE and void are (informally) opaque
types - you can't do anything to FILE* and void* directly, so return
value is essentially a bool.
Personally, since I can't declare f in the if(), and I believe in
initialisation on declaration, I'm still going to do
FILE* f = fopen();
if(f==NULL) {
// handle error
}
char* ptr = malloc(32);
if(ptr == NULL) {
// handle error
}
while( *p++ = *q++ );
<BEGIN RANT TYPE="IRRATIONAL, BORDERING ON CERTIFIABLY CRAZY">
I hate that idiom with a passion - a single statement that does seven
things, in an order implicitly dependent on operator precedence. Its
the archetypal victory of cleverness over clarity. Like obscure
technical jargon, its well understood by people who've seen it before,
but a royal pain in the arse to decipher on first exposure. Perfectly
fine in short, low level library functions - unspeakable as part of a
longer algorithm.
This is not Perl golf - unless you can demonstrate, using profiling
and disassembly, that
(i) the compiler will produce more efficient code
(ii) this efficiency actually matters to overall performance.
introducing barriers to comprehension merely to increase brevity is
premature optimisation, and premature optimisation is a very bad idea.
I want my high level code to read like pseudo-code -- the closer the
code looks is to a language-agnostic description of the algorithm, the
easier it is to see its correctness. Separating high and low level
details also makes it easier to refactor.
<END IRRATIONAL RANT>