Skip site navigation (1) Skip section navigation (2)

Re: sparse (static analyzer) report

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: sparse (static analyzer) report
Date: 2005-01-15 15:44:48
Message-ID: 87hdliu26n.fsf@stark.xeocode.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> 	if (ptr)
>
> Can anyone mount a good readability argument for one over the other?

My argument in favour of "if (ptr)" as well as "if (integer)" and "if (!ptr)"
is simply that all else being equal the shorter expression is clearer. Forcing
the reader to slog through additional syntax to read the code has a cost.

Obviously that argument is subject to abuse and it's very dependent on whether
you consider all else equal. 

For a reduction argument, pretending there's a boolean type with no casts
leads to the excessively verbose java-ish syntax like:

 if (foo != 0 && bar != null && baz != 0)

which you can't tell me is easier to read than

 if (foo && bar && baz)


What I miss most in both C and Java is the lispish ability to write
expressions like:

 foo = bar() || baz() || qux();

instead you have to write out things like this (except worse since you have to
start storing things in temporary variables):

 if (bar() != null) {
   foo = bar();
 } else if (baz() != 0) {
   foo = baz()
 } else {
   foo = qux();
 }

I've seen code that consists of a dozen or so of these things repeated. When
the code starts getting so verbose that what could be 12 very simple and clear
lines no longer fits on the screen because you're trying to make it easier to
understand, well, I think you've lost the battle.

-- 
greg


In response to

Responses

pgsql-hackers by date

Next:From: Marc G. FournierDate: 2005-01-15 19:54:11
Subject: Re: FATAL: catalog is missing 1 attribute(s) for relid
Previous:From: Devrim GUNDUZDate: 2005-01-15 13:51:31
Subject: Latest Turkish translation updates

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group