Subj : Re: Is well written code a rare species ?
To   : comp.programming
From : Joe Butler
Date : Mon Aug 15 2005 09:10 pm


"Chris Sonnack" <Chris@Sonnack.com> wrote in message
news:pfh1g1hu081sf38mdaoq28u8i21tkqcq6t@4ax.com...
> Joe Butler writes:
>
> > Your book example is a classic non-sequitur.  Books have nothing
> > to do with code layout...
>
> Well, the connection--which has already been discussed, I beleive--
> is just that overly long lines are harder on the eyes than short ones.
> Newspapers are printed in columns, in part, for that very reason.
>

Yes, I agree.  But I'm suggesting that an arbitarily-chosen cut-off is
counter productive.  I don't think anyone is claiming that the normal
distribution for readability and other good metrics is centered at 80
columns - which is why I find it so difficult to accept this rule.

A line that starts in column 1 that finishes at column 80 can get the
official thumbs up, whereas the same line starting at the first tab space is
required to line break because of the 3 or 4 character spillage.

> > type
> > function name(
> >     type parameter1, // comment
> >     type parameter2, // comment
> >     type parameter3 // comment
> >     type parameter4 // comment
> > ){
> >     blah blah
> > }
>
> I'm assuming "function name" is the function_name (or did you
> mean something else?  or does your language allow spaces in
> names?).  I'm assuming you meant this:
>
>     return_type
>     function_name (
>     [...]
>

Yes, of course - it was a sloppy example (blah is not a keyword, either).

> Which is a style I also favor.  Buys just a little more room
> on the function declaration line itself, PLUS it makes it very
> easy to search for the function definition--just search for
> where the name is on the left margin.
>
> I notice what I assume is a a typo above--a missing comma.

Yeah, I added the 4th parameter so that it went well over 80 characters and
cos it wasn't compiled, the mistake got past.

> To make those easier to spot, I often do something like this:
>
>     return_type
>     function_name ( type parameter1
>                   , type parameter2
>                   , type parameter3
>                   , type parameter4
>                   )
>     {
>         blah, blah, blah...
>     }
>
> I've learned over the years that the more *visual* structure I
> can put in code, the easier it is to work with.

I'd probably agree with the visual structure comment, but I find commas
floating out in space like that extremely jarring for some reason. The
compiler will always catch these errors anyway.

At the end of the day, the different styles add some variety - I wouldn't
constrain my programmers to such rigid rules.  I can easily identify the
author of a function or bug fix just by looking at the subtle differences
that each coder leaves behind (a sort of genetic fingerprint in ascii).  I
find that useful because it's then possible to go straight to the coder in
question if there are issues.  I can live with most of them except
'compressed' coding is fatiguing to deal with and 'exploded' coding styles
are just annoying because I can't understand the reasoning behind the style
and I guess I find it a little less scannable than other code.

// compressed (no spaces) yet, inexplicably, the braces
// are each placed on a line of their own - totally weird to me.
for(x=0,y=0;x<n;x++,y++)
{

}

// exploded code
for ( x = 0 , y = 0 ; x < n ; ++ x , ++ y ) {

}

// my own 'style'
for(x= 0, y= 0; x < n; x++, y++){

}

// not me cos of the pre-increment
// I know, it's more efficent (sometimes)
for (x= 0, y= 0; x < n; ++x, ++y)
{

}

.