80-column width

[Josh Sled]

On Fri, 2007-03-09 at 11:00 -0500, Perry E. Metzger wrote:
> You can rail against how stupid this is, but it won't get you very far
> with those of us who live this way. You can thus choose to make the
> code unreadable by a large chunk of the developer community, or stick
> to 80 columns.

I'm not saying it's stupid and it shouldn't make it "unreadable".
Actually, I'm suggesting the code is more readable.

I've made these arguments myself in the past...  literally, all the same
points you bring up.  I think they focus on the wrong things.  I'm also
not being capricious; I've spent years trying it both ways, and I find
the code is clearer with an 80-column guideline, but without an
80-column limit.


Editors shouldn't wrap preformated code.  In the common case, the bulk
of the code fits clearly w/in 80-columns ... with a few lines where the
ends trail off and need to be scrolled.  In my experience, you can get
the gist of the line from seeing the first 80 characters, and need to
scroll over very rarely.  My normal emacs window is 198x75, and I much
more often split it horizontally than vertically; when I do, though, I
can still fit code into the ~80-wide sub-windows, especially for
comparing stuff side-by-side.

Over-deep nesting is an orthogonal issue.  Similarly, too-long functions
are something else entirely.  I'm guilty of both, at times, but I'm not
looking for a 100-wide limit to work around either of those smells.

Printing to the page often requires reformatting (in other contexts as
well).  I don't think it is useful to optimize for this (increasingly)
special case.

Yes, some part of this proposal is due to editing files in 2007 on a big
monitor, with a good IDE, &c.  But that's how we spend 99% of our time,
so it's what we should focus on.


> As an aside, generally speaking, I think identifiers and type names
> are no longer than they were in the early 1980s. I also think humans
> are no smarter, so we can't deal with keeping larger blocks of code in
> our heads at once than we could 25 years ago.

Identifier lengths, perhaps ... function-local variables and class-local
field names tend to have the benefit of scoping and context to allow
them to continue to be short.  I think too much code uses meaningless
abbreviations, but ...

But functions and type names are clearly getting longer, especially as
libraries do more and higher-level stuff.  I think this is especially
true in C and Gnome-ville, where there's no language support for
packaging and aliasing (as in, say, Java and C#).


Take, for example,
http://svn.gnucash.org/trac/browser/gnucash/trunk/src/gnome-utils/gnc-tree-model-account.c#L55

We've taken to shortening names like these to something like
'gtma_[...]', and that works much -- but not all -- of the time.


Or, take for example the dozen cases from real code that I presented in
the previous email; those are reasonable cases from a not-exceptional
file.


> The biggest consideration in style choices is making sure as many
> people as possible can read and understand your code, since the

This is my motivation.  I think a >80-character unbroken line is more
readable than one "unnaturally" split at 80 columns.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo ${a}@${b}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20070309/4d8fd65a/attachment-0001.bin