Is the 80 Columns Limit Dead?

Dancing Primate asks: "Reading through the code of co-workers and various open source projects, I'm finding that people are no longer formatting their code to 80 columns. With most people using X and the wide range of non-vi editors, is the 80 column limitation disappearing? Am I the only one who gets grumpy when I do a diff or print code, and it's hard to read?"

Comments

The Way of the World

[Jason Scott]

As the administrator of TEXTFILES.COM, I can attest that it is certainly the case that modern writers who submit me works for the uploads section generally pay little or no attention to formatting along any given column length. Keep in mind that I always ask for these submissions in ASCII form, so this isn't the result of converting over from Word or StarOffice.

I think the reason I get files like this one is that people just let notepad and similar programs do the wrap for them. The fact that web browsers don't always wrap means you get some pretty funky looks.

This is not 100 percent true, of course: I've gotten submissions just this year that keep to the 80 column limit and include formatting taking advantage of it.

But on the whole, I think it's just that people no longer think of the world as sized in 80 columns, and we might as well understand that's the case. My heart will always be for the way it used to be, of course.

Re:The Way of the World

[eraserewind]

Auto-concat is not guarenteed to be correct, how can a system know which lines definitely should be joined? It can only guess by using some arbitrary rules?

Auto-split, since it is just splitting at the nearest word boundary to 80 will always be correct.

80 columns is a display issue, and should be handled by the system doing the display.

Re:huh?

[Rheingold]

You obviously haven't used the stock vi in Solaris recently...

Terminal too wide

80 columns lives

[bandy]

80 columns is still the default width of an xterm and Gnome Terminal window. Grumpy cow-orkers insist on sticking to 80 columns. It's a fact of life. Get used to it.

Readability

[rangek]

It is well known that beyond a certain width, readability drastically decreases. Here are some more links:

Some random "web development" site

Scroll down a bit to get to the chars per line bit

All of these basically agree that more than 80 chars per line is quite hard to read.

Re:U of Toronto

[saden1]

The current project I’m working on has set 120 columns as standard acceptable column width. This is of course the maximum characters you can print on an A4 paper in landscape layout.

We have 21" monitors and should and high resolution these days so I see no reason to stick with 80 columns.

Re:I'm sorry...

[0x0d0a]

The main reason for it is that (a) it lets people with default-width xterms and terminals read your code, and (b) it provides a reasonably universal standard to code around.

80 col seems pretty unused in the Windows world, where most people use that godawful Visual Studio Editor, and conventions are to extend lines to infinity.

80 col is common in the *IX world, where most folks doing a lot of coding are using emacs/xemacs or vi. Space-indented, 80 col code can be read by pretty much anyone and edited by anything, so it's a reasonably universal standard to base code on.

Some projects deviate from this -- it's considered good open source etiquette to stick with the format already being used in the file that you're hacking on, instead of mixing things up.

That being said, I rather like the idea of python's approach (where how the user chooses to view code, wrapped or scrolling, is independent of the storage format).

Re:That assumes...

[Dan Ost]

You should try Donald Knuth's CWEB environment. It combines coding and
documentation into a single deliverable. I really like some things about
it (the pretty printing is beautiful), but haven't made it my default yet.
Warning: requires a little TeX to take full advantage of the documentation aspect.

Check it out at http://www-cs-faculty.stanford.edu/~knuth/cweb.htm l

Re:72

[joeljkp]

Or if you write a lot of Fortran77 code (common in engineering).

Re:not really

[More Trouble]

You might be interested in the Unix commands "expand" and "unexpand".

:w

Re:not really

[Anonymous Coward]

A file with TAB indentation will look good only when your TAB width setting happens to match the author's, so when you open such a file you have to figure that out and change your TAB setting first (which gets old really fast).

Not if it's done correctly, i.e. you indent the code to the current indentation level using tabs, and never use them anywhere else.

You can add extra tabs to indicate a continued line, but you must not try to align it with anything on the previous line. If you need to line up characters on 2 lines, the lines must start with the same number of tabs (i.e. they must be at the same indentation level), and spaces must be used following the initial tabs.

It takes a bit of effort to follow these rules, but if you do, nobody should ever be able to tell which tab setting you used. Since tabs are only used at the beginning of a line, it doesn't matter whether a tab is expanded to X spaces or moves to the next tab stop.

IMHO, the worst problem is editors which mix tabs and spaces when indenting, assuming a tab is always 8 characters (such as mcedit when using "fake half tab" mode). If you use 4-space tabs, each pair of consecutive indentation levels end up at the same column; with 2-space tabs, deeper indentation levels are often displayed to the left of higher ones.

Re:More then 80 columns is fine

[Mr Z]

To fix the formatting: GNU indent

To print it nicely when you're done: vgrind

You're welcome.

--Joe

Re:Conventions are for the READER, not the author

[Mr Z]

I find tools like GNU indent to be handy for fixing grossly misformatted code. I don't like what they do to the subtlties of good code formatting.

For instance, suppose I'm doing the same operation with different parameters. Something like this (with periods to show the spaces):

some_funky_api (10, . 5, . .11, . 3);
some_funky_api ( 3, 113, MAGIC, 114);
some_funky_api ( 0, . 0, . . 0, . 0);
some_funky_api (33, .33, . .33, .33);

Now what happens if I run this through the typical code autoformatter? I get something like this:

some_funky_api (10, 5, 11, 3);
some_funky_api (3, 113, MAGIC, 114);
some_funky_api (0, 0, 0, 0);
some_funky_api (33, 33, 33, 33);

You see, sometimes you can subtly format your code such that the physical layout highlights the similarites and regularity of the code, and the text that remains highlights the differences. (Also, tools like "rectangular cut-n-paste" work well with code like that....) Automatic reformatters don't see that subtle layer of structure and destroy it.

That's why I'll only use them as a phase of cleaning up some horribly tab-damaged sh*t.

--Joe

Re:I don't get it

[Scarblac]

Perl does that, Python doesn't. I don't know about Ruby.

And Perl does it because those guys like giving you many options, it doesn't mean that actually using that is a good idea. Perl contains lots of possibilities that in 99% of the cases are a bad idea to use.