Subj : Re: Is well written code a rare species ?
To   : comp.programming
From : Joe Butler
Date : Sun Aug 14 2005 11:38 pm


"akarl" <fusionfive@comhem.se> wrote in message
news:%ONLe.31504$d5.184923@newsb.telia.net...
> 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.

My point is: regardless of whether you are right or wrong on the 80-columns
rule, the argument used to justify your case is wrong.  I.e. even if it is
agreeed that you are right about 80-columns, you are right for reasons that
have nothing to do with books.


> Overly long lines are simply hard to read.

Agreed.  There are plenty of cases where limiting to a fixed number of
characters also reduces readabilty.  An no one is advocating making lines
extra long just because we have the freedom to go over 80 characters.

> Moreover,
> there's no cost to wrapping text at 80 characters, and there is
> certainly potential benefit.

No, each line should be judged on its own merits.

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

Yes, and sometimes before 80 columns and sometimes after.  Each line
formated for best overal readabilty.


> >
> > 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.

Why?  (I assume you mean a function header comment.)
In my experience these things just stagnate. Makes no sense to me when there
is a more "tightly-coupled" place to put it.

>
> > 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)

In other words: "No problems if formated in a completely arbitary way that
we are so used to seeing that we never question."

.