[postgis-devel] STYLE

[Obe, Regina]

Alright if you like it perhaps I was a bit too harsh and that isn't the one that bothers me the most. How about this concession.

//OKAY
if (!binary) free(v); 

//NOT OKAY
if (!binary)
  free(v);

//NOT OKAY
if (!binary) free(v); printf(...);


The issue I have with the NOT OKAY is that its too easy for a python programmer or some other language that relies on indentation to screw this up.

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net on behalf of Mark Cave-Ayland
Sent: Fri 12/19/2008 10:34 AM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] STYLE
 
Obe, Regina wrote:

> This I mentioned to Mark offlist, but since its sort of a STYLE issue I 
> thought I would restate it here.
> 
> I know C programmers are in love with doing this short-cut. 
> 
> if (!binary) free(v);
> 
> I hate it.  It drives me crazy because its too prone to error when 
> someone comes
> by and tries to stuff another statement in there and forgets to put the 
> bracket in.

Aaargh - I really like this and use it a lot :(

The convention is fairly easy to read: if there are no {}s then only the 
next statement is considered part of the if... or else... clause. Does 
that help at all?


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel



-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20081219/83c6d850/attachment.html>