Re: Coding style for conditionals
"gwowen" <gwowen@gmail.com> ha scritto nel messaggio
news:271770ff-8795-4719-8437-72ae2268751a@z31g2000vbs.googlegroups.com...
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++ );
io> this below is clearer for me
io> while(9){*j=*i; if(*i==0) break; ++j; ++i;}
<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.
io> exist only what is written in the paper
io> so hidden ficturares, and macro that hide code, are wrong
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
io> brevity is good, what is not good is the brevity that not make
io> the aye to see what happen
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
io> the key point is if the languages scale well with complexity
io> and the complexity "kills" :)
easier it is to see its correctness. Separating high and low level
details also makes it easier to refactor.
<END IRRATIONAL RANT>