Slashdot Mirror
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?"
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....
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.
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.
With most people using X
The proper technology name is ActiveX.
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.
;), but sticking to 80 characters is truly limiting, especially these days when everyone has screens and editors that are capable of so much more.
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
(Spudley Strikes Again!)
If we don't format our code to 80 columns, then how will we maintain back-compatibility with IBM punch cards?!
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
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.
No, you don't understand. Imagine this:
- You log into a machine to check some logs.
- You adjust the screen size to read the long lines in the log files.
- You realize the you need to change a configuration file.
- You run vi to change the file, and it says, "Terminal too wide".
- You resize the terminal.
- You run vi to change the file, and it says, "Terminal too wide".
- You resize the terminal again.
- You run vi to change the file, and it says, "Terminal too wide".
- You resize the terminal again.
- You run vi to change the file, and it says, "Terminal too wide".
- You beat the every loving crap out of the Sun box.
Why the fuck is there a hard limit?!? In summary, I installed vim.Show me on the doll where his noodly appendage touched you.
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.
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).
May we never see th