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

U of Toronto

[beyonddeath]

I know in a lot of my coding classes at U of T they required no more than 80 characters on a line, lest you get some hefty mark deductions. I dont stick to it for my stuff tho i usually limit it to when my screen starts scrolling to the right....

Re:U of Toronto

[Dan Ost]

I generally limit my own code to 72 columns so that when I print 2 columns
in landscape mode with line numbers, there is no wrapping and enough white
space to the right of the code to make notes and such.

One of my beefs with Java is that it seems impossible to write comfortable code
in less than 120 columns.

I don't get it

[Dixie_Flatline]

Because of the way that people name their methods and variables now (int IHaveToDoABunchOfNiftyStuffHere( INT nThisIsAReallyImportantInt ) ) 80 columns isn't particularily feasible. That said, I don't understand why people don't just standardize on a column width and stick with it. When I first started working here, I tried to work within 80 columns, but my coworkers hated it when I reformatted their code, and I hated it when they touched mine. Now I format to 132 columns, and nobody really notices when I reformat their code to fit.

All the important stuff happens at the END of the line. It's where the actual methods get called and the work gets done. Seeing the beginning the line is usually entirely meaningless, and I hate scrolling to have to see the end of the line at 160 characters. I've already got my hands on the keyboard, and the mouse isn't a tool that I can use to input code, so it's just a waste of my time to put my hand on it. Most editors even indent and format the code pretty nicely if you manually break the line in a language like C or C++ which don't care about whitespace.

It doesn't really matter what the column width is as long as
1) Everyone sticks to it
2) You don't have to scroll to see the end of the line.

Re:I don't get it

[Vaevictis666]

I guess that's part of the reason some of the newer languages out there (Perl, Python, Ruby) allow post-conditionals.

die("The meat of the statement is at the front of the line") if Language.supports("post-conditionals");

More then 80 columns is fine

[stefanlasiewski]

You can violate the 80 column rule any time you want. Just do me one favor-- get rid of the tabs.

But remember, a 'tab' MUST be equal to 4 spaces or less. Destroy the tab character! Save the whitespace!

Nothing awakens the Hulk more then looking at code that someone indented with 8 tabs. Yarrrrg!

Re:More then 80 columns is fine

[mellon]

Right, what happens if you do this is that the bozo that has tabs=4 sometimes uses tabs and sometimes uses spaces, and then when you try to load it into an editor with 8-character tabs, the indentation is all screwy. Whereas if everybody uses 8-character tabs, which is the usual meaning of ascii character number 9, then this never happens.

The bottom line, though, is that this is a religious war, and as the person who's currently at the top of the list said, it's better for a team to just agree on what the indentation style is going to be, and stick with it. Otherwise you wind up with non-terminating flame wars (or terminated team members).

Re:72

[Dark$ide]

That was to allow for the sequence numbers on the cards in columns 73-80.

We're still suffering from the days of card readers and punches.

I've not punched a card since 1981. But I've edited lots of MVS (aka OS/390 aka z/OS) datasets that are fixed to 80 bytes (sequence in 73-80) by the architecture.

Re:Conventions are for the READER, not the author

[jc42]

I've written scripts and/or aliases to do just this on several projects. Somehow, the code-format nazis never seem to appreciate it.

But it makes a lot of sense to me. Different people have different preferences. Some have poor eyesight or are working on small displays or have to have too many windows open at once, and for them it makes sense to have narrow, vertically-formatted code. OTOH, people always complain about my tiny fonts and wide code, which I do because I find that I can only work on what I can see on the screen at once. Wasting a line to hold just a brace can materially limit what I can work on.

If someone with vision limitations wants to read my code, I'd encourage them to reformat it however is best for their eyes.

And in most languages, if your code can't handle this reformatting, there's something wrong with it. Canonicalizing it to a standard format shouldn't effect anything but its surface appearance.

There are a few languages for which this isn't quite true, of course.

Re:not really

[wotevah]

There are a few things in your post that you seem to feel strongly about, which are plainly false or wrong, and which made me think twice about replying. But I'll do it anyway.

First, the emacs interface is not idiotic. It's not idiot-friendly, I give you that. vi's and emacs' interfaces do not suck. They are however tools meant to increase productivity if you spend the effort to learn them. And they do. If you go by the definition that a good UI is one you can just start using, then they don't have a good UI. Their are powerful tools way beyond joe or pico or whatever it is you consider a good UI that is not "broken".

TAB is a special character. It is not printable, you need to convert it to a series of spaces to do that. Treating it as a character would mean inserting ONE item in the line, not a variable number depending on your current position.

Finally, think about it for a moment.
- A file with space indentation will look the same everywhere.
- 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).

The reason for that is that not all code starts on a TAB boundary, some of them may have a few more spaces (for example where wrapping a function call). Which begins to look nasty when your idea of what a TAB is differs from the author's. And don't say that everyone should use the standard 8-space TAB to fix that problem.

Lots of programs already use TAB for something else, emacs is not the only one. Bash is another one. Any decent command-line interface now uses TAB for auto-completion. I'm sure there are other examples. If TAB were really a character they would just display it instead, I suppose.

Re:72

[ffsnjb]

72 column is required in most COBOL environments I've worked in. *shudders*

Actually, I should put COBOl experience on my resume, I could probably score a really badass job with that. All of the old COBOL hackers are dying. Someone has to port that legacy code eventually.

Re:Conventions are for the READER, not the author

[irc.goatse.cx troll]

The first one makes code folding useless.
I'd paste an example, but the slapdash lameness filter won't let me, so just paste the code into vim, add (expression) after the if statement (not needed, but shows a point), and set these things:

:set foldenable
:set foldmarker={,}
:set foldmethod=marker

then "zc" while on the if { line and it should collapse all of that block down to one line showing the if statement, indentation level, and how many lines are folded. Now try it on the first method, and it has no idea what the if statement is which now awkwardly sits on top.
Which ones easier to work with?