[TUHS] 80 columns ...

[davida@pobox.com (David Arnold)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2771 bytes --]

(apologies for prolonging this thread)

For me, context is everything while programming.  Header, code, the other code, man page, spec doc, etc.  I usually manage that by getting as many “terminals” as I can on screen: 4 side-by-side xterms, 80 rows of 80 columns using 6x13 font on my 1920x1200 screen.  The choice of 80 columns, as has been pointed out, is arbitrary (and historical), but I find it’s a reasonable compromise between clarity of the code (minimal line breaking) and maximising context (4 columns, rather than fewer).  If you’re using 132 columns, you almost completely eliminate line-wrapping, but you’re also wasting a lot of visual real estate as the great majority of lines are less then half that long.

That said, 80 columns doesn’t work for Java: C is fine, C++ mostly ok, Python is ok, but with Java, the naming culture is for incrediblyLongDescriptiveNamesForEveryThing, and even 132 columns can be too tight.

To be honest though, it’s vertical space that I find more important: being able to see the entire function, or all the related header definitions, etc, without scrolling means far less cognitive overhead.  Four lots of 80 rows is *so* much better than one lot of 24 as to be almost indescribably more productive.



d


> On 11 Nov 2017, at 07:46, Warner Losh <imp at bsdimp.com> wrote:
> 
> 
> 
> On Fri, Nov 10, 2017 at 1:39 PM, Larry McVoy <lm at mcvoy.com <mailto:lm at mcvoy.com>> wrote:
> > > Separate from this, I think that the whole 80 column thing is a bit silly.
> > > I have used 132 as by default for a long time now.
> >
> > Just don't move on without some limit. There are real
> > cognitive/typographic reasons why excessively long lines hurt
> > comprehension. This is why both 500 year old books and 5 month old books
> > have narrow measures.
> 
> I've made that point and people blithely ignore it.
> 
> When I was debating style wars in the 90's, we adopted a 'wide is OK' approach, but with a soft limit of ~130 and a hard limit of 160 in exceptional cases. There was some research that showed that there's a limited field of view you want to be able to look at the code without moving your eyes side to side, just up and down. With the technology of the time, above about 130 would be hard to read 'at a glance'. Years later, I went looking for those studies, and couldn't find them and the original advocate of the view couldn't provide them.
> 
> I'm the first to admit that 80 is too few. But 200 is definitely too wide and 100-120 seems to still be the sweet spot for my eyes and the range of hardware that I use.
> 
> Warner

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171111/4c091ecf/attachment.html>