Subj : Re: Is well written code a rare species ?
To   : comp.programming
From : akarl
Date : Sun Aug 14 2005 09:27 pm

Joe Butler wrote:
> Maybe so for an 80 column terminal.  But we were equipped with some
> new-fangled graphical monitors.  They comfortably display more than 80
> characters per line.
> 
> Your book example is a classic non-sequitur.  

Books are formatted to be read by humans and source code is too. I don't 
see your point. Overly long lines are simply hard to read. Moreover, 
there's no cost to wrapping text at 80 characters, and there is 
certainly potential benefit.

> I wonder if your style of
> parenthises, commas, etc. also follow book style (e.g. spaces after commas,
> no space on the inside of parenthasis, etc.).

Sure, absolutely.

> Let's just close with an example of why sticking religiously to 80-column
> layout is so dumb (unless you are restricted to a text terminal):
> 
> ... ------70------80
> .... stuff * dist_val +
> x;
> 
> instead of
> .... stuff * dist_val + x;

I think the best approach is to start a continued expression with an 
operator, like this:

    y := stuff * distVal
       + x

Even if you use more than 80 columns you probably need to break lines 
sometimes anyway.

> This was also given as one of the justifications for the 80-column layout -
> so that the code printed out on paper well.  The silly thing was that the
> code was hardly ever printed out (> 99% of the time we were working with it
> on screen).  Any code that was printed was for debugging purposes and got
> binned within minutes of being printed.  No one questioned if landscape
> format might have been a better printing option.  So, you see, it didn't
> make any sense - but what added insult to injury was the team went
> apoplectic when I started to format my functions thus:
> 
> type
> function name(
>     type parameter1, // comment
>     type parameter2, // comment
>     type parameter3 // comment
>     type parameter4 // comment
> ){
>     blah blah
> }

If the type and function identifiers are very long I'd write the 
function header as something like

    type function_name(type parameter1
       type parameter2, type parameter3,
       type parameter4);

However, the comments for the parameters should go in the documentation 
of the function.

> This style was described as "unreadable".  I do not exagerate: some of the
> team almost fainted.  That tells me a lot about those programmers.
> 
> They had been indoctrinated into the following style:
> 
> type function name(type parameter1, type parameter2, type parameter3, type
> parameter4)
 >
> (I don't know how they managed to reconcile this when it violated the
> 80-column rule.)

No problems if formatted as it should be:

    type function_name(type parameter1, type parameter2, type parameter3,
                       type parameter4)


August

.