On 80 columns should (not) be enough for everyone

[Nick Sabalausky]

"Andrej Mitrovic" <andrej.mitrovich at gmail.com> wrote in message 
news:ii46g5$1g66$1 at digitalmars.com...
> The unittest topic is about to get derailed so I want to continue this 
> silly discussion here.
>
> Wheres Nick? I want to see the CRT vs LCD discussion heated up again with 
> Andrei claiming that LCDs are so Godlike but yet claims 80 columns is 
> enough for everyone.
>

Heh :)

This is what I do: My editor shows a faint vertical line at the end of 
column 80. I use that as a rough general guideline, but not a hard-and-fast 
rule.

I agree with Andrei that the longer a line of code or text gets beyond 80 
columns, the harder it gets to read. Heck, I had one co-worker once who had 
his code total-fullscreen on a 16:9 with lines extending all the way to the 
end: it was horrible. I do think you can go a little bit further than 80 
columns while still being perfectly readable, but I think 80 is a sensible 
time-honered rule of thumb for maximum compatibility as long as you're not 
too strict about it.

One other reason to not be too strict about the 80-column guideline is 
elastic tabstops. With those, propotional fonts become perfectly sensible to 
use for code, and then "80-columns" inherently becomes "fuzzy".

Minor side note: Vertical space being much more important than horizontal 
for both code and other text is the primary reason I'd never consider 
getting a widescreen monitor. (For TV's I can go either way, though, as long 
as the non-widescreen can properly scale/letterbox widescreen signals.)


> 80 colums is an artifact of the old age. Just like the preprocessor is an 
> artifact of the C language. And many other old things are artifacts. 
> There's no reason to keep these artifacts around anymore.
>

Like Andrei said, it may not be a technical limitation anymore, but it is 
still a human limitation. Any remotely modern computer is perfectly capable 
of speeding up voice playback by 10x, but nobody does it that fast because 
the human user is the limiting factor.

Of course, if someone said "let's use 90 or 100 lines as the guideline", I 
wouldn't object at all. But 80 has a lot of history behind it, and is 
therefore much easier to agree on as a rough standard, and it does still 
work out, again, as long as you're not too strict about it. (And it doesn't 
hurt that I'm a fan of both powers-of-two and the 1980's, so there's that 
nice warm psychological connection ;) )


> A couple of things, Andrei:
> 1. 80 colums is way too restrictive. 80 columns wasn't determined by some 
> scientific method to be a good size for code, it's a product of 
> limitations of the older generation hardware. Who will run a brand new 
> language like D in a freakin' Terminal?
>

There's a lot of text-mode junkies out there. And for Unix users, there may 
be times when they need to work in pure text-mode. Also, it's common to have 
a million other frames showing (see a typical Eclipse setup), so that can 
really limit how many columns people have available, too.


> If you want to see more files on the screen, get multiple screens. Is 
> Facebook running out of money, can't they afford a few monitors for the 
> C++ guru? Yes, I know you're not allowed to comment on that one. :)
>

He probably already has as many as his cubicle will hold ;)


> 2. A widescreen aspect ratio causes less eye strain. Wider code means the 
> same.
>

That's just plain rediculous. I don't know where you got that. *Maybe* for 
watching video, but certainly not text.


> 3. Less columns means more rows. And generally coders *hate* it when they 
> can't see a function that fits on a single screen. They hate having to 
> scroll up and down. This common syntax form is a proof of that:
> void main() {
>    void foo() {
>         while (true) {
>             if (done) {
>             }
>         }
>     }
> }
>
> I find that unpleasant to read. Not impossible, but unpleasant. I can live 
> with it though, but if you limit code to 80 limits that's going to become 
> a mess to read.
>

FWIW, I'd write that this way:

void main()
{
    void foo()
    {
       while(true)
       if(done)
       {
       }
    }
}

I'm a big fan of "stacking" flow-control statements like that whenever the 
outer statements don't have anything else in their body.

Like this (stupid example):

// Draw funny design (and yes, this could be optimized better)
if(shouldRefresh)
foreach(int x; 0..width)
foreach(int y; 0..height)
if(x ^ y < width*height / 2)
    buffer[x + y*width] = palette[(x+y) % $];

Instead of something more like:

// Draw funny design (and yes, this could be optimized better)
if(shouldRefresh)
{
    foreach(int x; 0..width)
    {
        foreach(int y; 0..height)
        {
            if(x ^ y < width*height / 2)
                buffer[x + y*width] = palette[(x+y) % $];
        }
    }
}

> 3. It's 2010. Does your GNU/emacs still not support wrapping lines by word 
> boundaries? Scite had this since the '90s, and that's not even an advanced 
> editor. Vim supports word wrapping as well. Heck, I'm pretty sure you can 
> customize it to wrap on whatever boundary you want to (although I'm only 
> speculating, but pretty much everything in Vim is customizable). You can 
> even customize how your cursor reacts if it's on an 'artificial' new line, 
> one that has been wrapped.
>

That's not a bad point. But if a line is that long, it's going to be 
difficult to read anyway without doing it manually and taking syntax into 
acount:

auto str = join(formatStr1, formatStr2, formatStr3, formatStr4,
    formatStr5).format(someValue1, someValue2, cond? ""
    : someStr, someValue3 + someValue4);

Vs:

auto str =
    join(
        formatStr1, formatStr2, formatStr3,
        formatStr4, formatStr5 )
    .format(
        someValue1,
        someValue2,
        cond? "" : someStr,
        someValue3 + someValue4 );

I find the second one perfectly readable, but I can't even make head or 
tails of the first one, and I just wrote it a few seconds ago!


>
> 4. Just how many files do you want to edit at a single time on the screen? 
> We're not really multitasking beings, you know.

I'm rarely editing only one file at a time. Frequently a whole handful. (But 
I "Ctrl-Tab" through them.)


> If you really want to set up a column limit that *everyone* has to abide 
> to, then make a poll to see what everyone can agree on. I don't see why 
> everyone has to cater to your rules only, regardless of what your 
> professional experience might be. You're a big contributor to Phobos, but 
> you're not the only one. I tend to believe that D is (or should be) a 
> community effort, so please don't hijack D away from the community by 
> forcing your own rules down to everyone else.

Sounds fair. (But I'm not a Phobos dev, so my opinion on that is probably 
irrelevent.)