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.

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.

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:huh?

[Rheingold]

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

Terminal too wide

Error

[Anonymous Coward]

With most people using X

The proper technology name is ActiveX.

It's been dead a long while.

[Spudley]

You've only just noticed, eh? Methinks you've had your head stuck in the sands of the character-based terminal a bit too long.

The only reason I can think of to keep using 80 character lines now is if you're writing in COBOL (which forces the issue). For anything else, you can either write your lines as long as you need them (if you're programming), or you turn on word-wrap (if you're doing anything else).

When I say 'as long as you need them', that isn't an invitation to write programs with 700-character lines; I mean, there's still a requirement for a degree of common sense, even for programmers ;), but sticking to 80 characters is truly limiting, especially these days when everyone has screens and editors that are capable of so much more.

Never!

[Dr. Photo]

If we don't format our code to 80 columns, then how will we maintain back-compatibility with IBM punch cards?!

Conventions are for the READER, not the author

[rossifer]

What kills me is how few people realize that code conventions are not for their own personal readability of the code they write. Code conventions are for the benefit of the tens and possibly hundreds of people who are going to be reading the code well after you've moved on to another position.

Also, for all of the people who assert that their convention (braces on the next line/end of previous line) is scientifically backed to be more readable than the alternative: most of the time, it doesn't matter nearly as much as consistency and being able to have the whole team agree.

I happen to be the "conventions nazi" in my office (I was also the "unit test nazi" until we bought a tool that did it better than I could). I'm not an asshole about this issue because I'm a control freak, I'm an asshole because conventions really matter to the long term future of the project.

The right way to be the "conventions nazi" is to get everyone into a room, get everyone to agree that consistency matters more than personal preference, then go down the list of issues and get some consensus (voting works well) on each one. Lone holdouts may need frequent reminding of the "consistency over personal preference" point. Don't leave the room until you have a set of conventions that (1) keep the code consistent in important ways (2) isn't so huge that nobody could hope to remember them and (3) can be easily supported by the tools commonly used by team members.

Our convention is 132 characters on a line. Inner classes and Java/C++ class/method/variable naming conventions make 80 characters simply impractical. After trying it for a while, there were so many broken lines that the code was simply less readable. So we changed the convention and even though I was for 80 characters, I'm fairly happy with the improved readability of the code.

Regards,
Ross

Re:Conventions are for the READER, not the author

[Elwood P Dowd]

As a VB coder who frequently gets lost in his own code while he's writing it, I'd like to assert that my code conventions are for my own personal readablity of the code that I write. If I went much over 60 chars per line, I'd have to scroll all the time to see the stuff that just ran under the File Explorer or the Properties Explorer or the control pallette. My usual response to this is to totally forget what function I was working on, and why.

Oh, my God, I wish I was joking.

Re:Conventions are for the READER, not the author

[ttfkam]

So tell me. How much should I respect you if I am your boss? You've just told me that despite the myriad choices and possibilities available in programming that you cannot adapt to a simple change in bracing style.

If it takes you more than a week to get accustomed to a new formatting style, you will forgive me if I doubt your ability to adapt to a new compiler or new editor or new operating system or development library.

And please stop with the strawman of forbidding polymorphism. Yes, there are moronic shops that forbid certain practices that can be instrumental in solving certain problems. But the parent clearly wasn't talking about those instances. This wasn't a discussion of functionality, it was about aesthetics. Deciding about the amount of whitespace, the capitalization patterns, the bracing style, and the line length do not fall under your diatribe.

And frankly, if you cannot adapt from

if (1) {
}

to

if (1)
{
}

to

if ( 1 )
{
}

or from

write_file()

to

writeFile ()

to

Write_File( )

your problems extend far deeper than your code style.

The question boils down to, "Which formatting style is best?" The answer is simple: "Whatever everyone else on your team is doing." If you cannot adapt to something as simple as this, you cannot be effective in a team. If you cannot be on a team, you are fundamentally useless to 99% of all projects out there. There are better ways to express yourself in code than through bracing style. If formatting style is the best way you can assert your skills and individuality, what does that say about your skills as a programmer overall?

Have a nice day.

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?

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:More then 80 columns is fine

[Tumbleweed]

Okay, Hulk, that's just dumb. You _want_ indentation to be done via tabs - that way everyone can set the tab to _display_ as as many characters as they want. How many 'spaces' (equivalent) a tab displays should be up to your text editor of choice. The original author can display their tab characters as equivalent to 8 or whatever, and you can view it as 4 or whatever. That's the genius of using tabs for indentation.

Re:huh?

[pyrrhonist]

Do you really need line coded that long?

No, you don't understand. Imagine this:

1. You log into a machine to check some logs.
2. You adjust the screen size to read the long lines in the log files.
3. You realize the you need to change a configuration file.
4. You run vi to change the file, and it says, "Terminal too wide".
5. You resize the terminal.
6. You run vi to change the file, and it says, "Terminal too wide".
7. You resize the terminal again.
8. You run vi to change the file, and it says, "Terminal too wide".
9. You resize the terminal again.
10. You run vi to change the file, and it says, "Terminal too wide".
11. You beat the every loving crap out of the Sun box.

Why the fuck is there a hard limit?!? In summary, I installed vim.

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: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: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).

well-known saying...

[Polo]

It's well known that the saying "80 column mind" means that you're narrow minded. Google it. :)

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:yes it does

[Mr. Slippery]

Why are you printing code in 12 point font?! You can buy reading glasses in any pharmacy/ convenience store for a few bucks, btw.

If you print and display at a decent size, you won't end up needing reading glasses...

Don't strain your eyes - you only get one pair.

Re:huh?

[Gumshoe]

Why the fuck is there a hard limit?!? In summary, I installed vim.

In my early UNIX sysadmin career when I was learning the ropes, I was admonished by my boss when he realised I was using vim instead of vi. His reasoning as far as I could gather was that vi is universal and vim isn't and that I might "learn bad habits" by using vim and "become unstuck" if I ever needed to config a machine that doesn't have vim installed.

Even in my inexperienced youth I realised that there's a line in the sand between UNIX advocacy and clueless lunacy and that he had crossed it.