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?"
Why would vi have any problem with long lines?
when printing a monospace 12 point font on a piece of paper.
The One Rule Of Chess You'll Ever Need: Don't play someone who carries a kit in their bookbag.
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!)
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
As far as text documents go I find text to be easier to read when people don't assume a certain display width. I commonly have several applications open and very little screen space left for my notepad text window.
I think people replying to emails with a cutoff of 40-80 characters can be really difficult to read since I usually use a large window to read their emails and that sometimes leaves a whole 2/3rds of the window blank.
Source code should have reasonable but flexible limits. A width of 80 sounds low but as long as the code is readable on a modern monitor I don't find any problems with it. When you start indenting with spaces instead of tabs just to keep within 80 or 72 characters width then it just gets ridiculous.
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.
Reasonable, however here is my rationale for wanting to stick to something less with code - you can have 2 files open at the same time, visible next to each other, at the same time, with maximum height.. all screen real estate used. I find this really convenient for having two .c files open, where one is calling the other, or a .c file and a .h file, etc..
The advantage of using 80 columns is that you can have multiple source lines on screen.
At 1152x864, you can slap four xterms with the default fixed 9 font onscreen, and refer easily to headers and other code.
I view X as particularly useful because I can *have* four terminals onscreen at once, though I can make any bigger if I feel like it or my eyes are tired.
May we never see th
1) Everyone sticks to it
2) You don't have to scroll to see the end of the line.
I disagree. Reading short lines is less tiresome than reading long lines. This is the reason why most newspapers use rather narrow columns in print.
When lines are logically longer than 80 chars, I use line breaks to make them fit.. not too difficult, and I find that several short lines of method calls are much easier to read than a single long line.
When looking at another programmer's code, it's very convienent to print it,
write notes, questions, and corrections on it, and then give it to them. If the
code doesn't print well, then this becomes more difficult to do. If the code
is unprintable, then you're reduced to writing notes some place else (email?)
and referencing line numbers which is far less natural than simply writing
notes beside the code in question.
*sigh* back to work...
The reason why it's good idea to still keep stuff in 80 columns, is that while you CAN fit much more on modern terminals, you might not WANT to. Specifically, I DO format to 80 columns, because that's about as much as fits to my standard ViM window. My resolution is 1280x1024, and I'm using a 8pt font in 96dpi. Oh, and my ViM is fullscreen... The catch is, when the code is split to 80 columns, I can view TWO source files side by side. This also goes with terminals: having two (actually four, one in each "corner") is very nice. So yes, I think that 80 columns per row IS still a good rule.
Software should be free as in speech, but if we also get some free beer, all the better.
Your example may not be the best. It's usually really important to know what the hell the condition is. That's why it's generally a good idea to:
if something
x
else
y
end
That being said, postconditionals make the code flow much better and are excellent for short single choices (i.e. just an if, not an if-else).
Marxist evolution is just N generations away!
This is true. But the REASON it is easier to read prose is that your eyes don't have to "carriage return" so far after each line. So a line of code really shouldn't be more than 70-80 characters wide for the same reason.
So lets say you are using 5 space indents and you want to be able to indent 5 levels comfortably (usually I have found that more than five levels means something is wrong with the code). That is 105 chars per line.
Fortran95 for example will only swallow upto 132 chars per line. So I could see a few lines hanging out there at a hundred-something. In practice (perl and fortran95), I have never felt the need to go over 132 characters in a line...
It is not up to HTML to tell you how to display the information per say. With a comfortably sized browser window everything should wrap.
Marxist evolution is just N generations away!
In the end, ASCII (which all good e-mail should be presuming it's in English), there is no such thing as a hard linebreak versus a soft linebreak. In desktop publishing such a thing exists. E-mail as a general rule doesn't have a well defined, broadly implemented standard for such a beast.
Which is precisely his beef. It's relatively straightforward a paragraph all on one line into arbitrary length lines (in this case, there are only hard-breaks, and the text viewer implements softbreaks for you). However, it's painful to join things that aren't 80 characters together. The text viewer can't tell if you meant that carriage return to be a softbreak or a hardbreak. On a hardbreak it shouldn't join the two lines, on a softbreak it should. A lot of people aren't terribly consistant (I'm not for example), and their e-mails are a pain to read in an auto-formatted text viewer. I've cringed on more then on occasion when someone quotes my e-mail on a list when they use a 60 char line breaking, and I use 72 char line breaking. Then the last 12-20 characters get split onto their own line. It just looks horrible.
There is some header that can affect this along lines of "Text-flowed" in the Mime Headers, so that things word wrap properly (essentially, your text has soft line breaks, and hard line breaks), where as standard ASCII has no such concept.
I use mutt with vim as my text viewer. I've been known to re-format e-mails on a fairly regular basis and re-save them to be readable to me. I do the interpretation of soft vs. hard breaks and save it so it's easy to read (for me).
Stop being so hard headed and assuming the other guy's just an anal retentive prick. He's got a legitimate point that the interpretation of line breaks is very difficult.
Kirby
The solution is something like:
[tab][tab]some_function(parm,
[tab][tab][_14_spaces__]other_parm,
[tab][tab][_14_spaces__]one_more_parm);
Tabs are useless for this kind of alignment, but that doesn't rule them out completely. Tab until you hit the correct indentation level, then switch to spaces to align. In the above example, you could replace [tab] with any number of spaces, and it would still align.
Never use tabs except to get to the correct identation level. If there have been 2 "{"s and no "}"s so far, each line should be indented using 2 tabs, and no tabs should appear anywhere else (except maybe an extra X tabs to indicate a line was continued, but don't use them align anything).
Except that you can't send the diffs to another person, attach them to bug reports, etc.
And some more reasons not to do automatic reformatting:
- formatters can't fix aything non-syntax related, like strange variable naming conventions.
- reformatting makes your environment completely different from everyone else's (including your coworkers and customers). Eg: stack traces you get on one machine are completely different compared to the ones you get.
Having a code convention (and sticking to it) makes everyone's life easier in the long run.
-- "So, what's the deal with Auntie Gerschwitz et all?"
This is true for english prose, but is *not* the case with code. Having all the code on one line is usually more readable even if the line is very long. This is easy to prove, just try it.
Having lines that are long is especially useful when you have some sort of repeating pattern that makes a nice column down the screen (either very similar code or a data structure). Wrapping lines in this case royally screws the readability.
-David
There. Now go play some cool javascript games!
It often looks like hell when I try to read that sort of text on my Handspring Visor. Why not delegate wrapping to the viewing software.
The 'many programs' that can't wrap are broken.
resigned
The more brain-dead coders don't realize that they have a windowing environment, and run with all of their windows maximized, preventing them from taking advantage of any of the benefits thereof. They produce bizarre lines that are over 150 characters wide, and they're slower than hell, because they have to cycle through all of their programs to find the docs or the other files they're working on. It's particularly hard for them when they're using a fancy schmancy editor, so they can't even Alt-Tab through their editing windows.
Maybe I'm old fashioned, but I know what works, and what doesn't. Over many, many years of coding, I've used dozens of IDEs and operating environments, going way back to Borland Turbo C++ for DOS, using Visual C++, and even Eclipse. After many years of experimenting, I've settled on ViM and the command line for most tasks. It's just easier and more efficient for a trained user.
One of my beefs with Java is that it seems impossible to write comfortable code
in less than 120 columns.
I see no reason why you should have a problem with that. I write Java in my job, and rarely exceed my editor window's default width, which is 94 columns. Are you using 8 column indents, by any chance?