Re: Is 80-column source code formatting still standard ?

André Pang <[email protected]> writes:
> On 29/06/2008, at 1:12 PM, Daniel Pittman wrote:
>
>>> I don't think it'll be hard to find cases where a 160-character line
>>> is a lot more maintainable than trying to split it into 3 or 4 lines
>>> of 50 columns each.
>>
>> I, personally, do, simply because I don't know of any editors out there
>> which are particularly intelligent about word-wrapping wide columns.
>>
>> You can break the expression into four lines by hand in a much more
>> sensible way than an arbitrary 80 (or 90, or 100, all of which are
>> common enough) column cut-off.
>>
>> That 80 column point may be half way between words, or in the middle of
>> a sub-expression, or any number of other bad choices.
>
> I think you're assuming that I use 80 columns for my text editing
> width, which I typically don't.  

That is a fair point, and I wasn't entirely clear on my reasoning here.

> I usually view around 160-200 columns when editing code, so word
> wrapping isn't a problem for most lines.  

My thinking, when I wrote that, was that 90 percent of the life of your
software is going to be maintenance, and almost every real world project
will go through the hands of at least two developers in that time.

So, in a case where (e.g.) you write your wide code, then I get called
in as a maintenance programmer we have an issue -- I use a much narrower
display than you do.[1]

At that point I end up with those problems I described: because I use a
smaller display, nasty word-wrap issues crop up.


So, in part I think that breaking the expression by hand to the smaller
limit is kind to all the other people that will work on the code.

(...and, yes, a project that only one person ever sees doesn't matter
 for this.  I don't know they are terribly interesting to discuss,
 though, because if no one ever sees it then, hey, it doesn't really
 matter what it looks like, no?)

> (I'll restrict my margin to 80 columns when the coding standards for
> the project wants me to, of course.)

That is good: if I was working on your project then, yes, I would figure
out some way to code up to 160 columns wide, also.  Sticking with the
current standard is almost always better than replacing it.


> I think a more apt analogy than comparison with English text and
> newspapers is breaking up a long mathematical expression over three or
> four lines rather than keeping it on a single line: sometimes it's
> clearer; sometimes it's not.  

I agree with that: sometimes extra space really does make it that much
more comprehensible.  

I get the impression that what I see as an incredibly uncommon exception
to the process -- a line that really, truly justifies that exception --
is something you routinely find.

If that was also my experience I would probably tend toward agreeing
with you.   (Well, that, or I would spend a lot of time cursing. ;)

> My overall point is that the nature of what you're trying to convey in
> the code should be the biggest contributor to whether short or long
> lines work better, and it's not just about the optimal column width
> for reading.

I agree with your overall point, which is great.  We can debate the
details endlessly, I guess, but I am happy to more or less agree with
you.

I think, personally, that reading width is a significant contribution to
the overall utility of the code but, lacking anything better than
opinion to support it at this stage, will happily shut up about that. ;)

Regards,
        Daniel

Footnotes: 
[1]  90 columns, giving me a small margin for (limited) overflow
     from a standard 80 column margin.

-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html