Is the 80 Columns Limit Dead? 317
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?"
U of Toronto (Score:4, Interesting)
Re:U of Toronto (Score:3, Informative)
We have 21" monitors and should and high resolution these days so I see no reason to stick with 80 columns.
Re:U of Toronto (Score:4, Interesting)
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.
Re:U of Toronto (Score:3, Insightful)
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?
huh? (Score:3, Insightful)
Re:huh? (Score:4, Informative)
Re:huh? (Score:5, Insightful)
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.Re:huh? (Score:2)
Re:huh? (Score:3, Insightful)
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 U
Re:huh? (Score:2)
yes it does (Score:3, Insightful)
Re:yes it does (Score:2)
Re:yes it does (Score:3, Insightful)
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.
The Way of the World (Score:5, Informative)
I think the reason I get files like this one [textfiles.com] 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 [textfiles.com] 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 [textfiles.com], of course.
Re:The Way of the World (Score:3, Insightful)
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 lo
Re:The Way of the World (Score:3, Informative)
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:The Way of the World (Score:3, Insightful)
Now, that would look just stupid if it was like this:
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
I don't get it (Score:5, Interesting)
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 (Score:3, Interesting)
die("The meat of the statement is at the front of the line") if Language.supports("post-conditionals");
Re:I don't get it (Score:3, Insightful)
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).
Re:I don't get it (Score:3, Informative)
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.
Re:I don't get it (Score:2, Insightful)
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.
Re:I don't get it (Score:3, Insightful)
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
um news flash (Score:2)
No seriously on Linux use svgatextmode if you can or a framebuffer driver and try to expand the columns on your screen. Or just use X / windows elsewhere.
80 columns is thought of as old.
Re:um news flash (Score:2)
What about people using PDA or cellphone-based ssh
clients?
slrn? Mutt?
My Apple
I generally find those who advocate ditching the 80-column standard are the same ones who have no problem with HTML-ized email.
Bah. Feh.
Re:um news flash (Score:2)
Stop insisting that the rest of the world conform to your display preferences. 80-column ASCII is the lowest common denominator. All your gee-whiz eye-candy isn't going to change that.
Or do you want all your SMS messages to include 50k of XML markup? After all, you should BUY A REAL COMPUTER, as you say.
How about we bog down your cellphone with 500k emails that say nothing but, "I'll be home at 5", because they're XML-ized
Re:um news flash (Score:3, Insightful)
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.
Re:um news flash (Score:2)
side on my laptop. I run at a higher resolution on my workstation and will
lengthen my xterms, but I like to stick to 80 or 88 columns wide. I've tried
coding in 132 columns, but find that long lines are unwieldy to read and write.
Error (Score:4, Funny)
The proper technology name is ActiveX.
Re:Error (Score:2)
80 columns lives (Score:3, Informative)
Re:80 columns lives (Score:2)
80? I thought it was 72! (Score:2)
But it's not as annoying as printing the output from SQL statements in M$ Query Analizer... especially when there is a text(16) field in the output that needs analising!
It's been dead a long while. (Score:5, Insightful)
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
Re:It's been dead a long while. (Score:2)
Oh, I dunno. Some years back, a particularly obnoxious programmer on the team produced a ridiculously-long routine to do a certain task. I opined that I could do it in a lot less code. His response was something sarcastic along the lines of "Oh, yeah; I suppose you could do it in one line of C." I paused a few beats, and said that, yes, I could. He sneered at this, so I offered a wager, whi
Re:It's been dead a long while. (Score:3, Insightful)
The line-wrap feature is killer.
Put line numbers in the giutter
it prints to printer with line-wrap.
use code-to-html plugin for pretty web output
code your code without worrying about all that.
Of course, otherwise it doesn't fit on my... (Score:3, Funny)
Was there a limit?! Oh My Goodness! (Score:2)
I guess that's why most of my old code is impossible to maintain. In search of something better, I switched to Python because of ESR recommendation [linuxjournal.com] and I really, really like it. The forced syntax makes my code a lot more readable. Although I've been struggling to switch my LAMP coding from Linux/Apache/MySQL/PHP to Linux/Apache/MySQL/Python, I'm hoping it will be easier to maintain.
I think I'll b
Never! (Score:5, Funny)
Re:Never! (Score:2)
(Cryptonomicon)
More then 80 columns is fine (Score:3, Interesting)
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 (Score:5, Insightful)
Re:More then 80 columns is fine (Score:2)
I was just trying to find a bug in some code written by a number of different authors: One guy used tabs, one used sets of 4 spaces, one guy used sets of 2 spaces... and of course, 8 indents means 8 nested statements. it's easy to get lost in there.
Re:More then 80 columns is fine (Score:2)
Yeah, that would involve a series of search & replaces just to get it to the point of readability. There might be some programs out that that fix formatting problems like that for you; certainly worth looking for.
Re:More then 80 columns is fine (Score:2)
This would be true in a system without hard line breaks. In a hard-line-broken environment, be it 80 col, 120 col, 132 col, or whatever.
However, if you start changing tab width around, consistent line length goes to hell (not bad if you're shortening tabs, but if you lengthen them, you have a bunch of lines that are badly broken).
This is a long, long debate.
Re:More then 80 columns is fine (Score:2)
Re:More then 80 columns is fine (Score:4, Interesting)
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:More then 80 columns is fine (Score:2)
Re:More then 80 columns is fine (Score:2)
Re:More then 80 columns is fine (Score:2)
Only if they're crappy, and aren't configurable, or if they're misconfigured. If you can get everyone to agree on a 'tab width,' then you can get everyone to agree on using tabs for indentation. Then it's just a matter of using a decent text editor to let you display those tabs however you wish. Getting people to agree on using tabs consistently should be easier than getting people to agree on using a specific 'width.'
Re:More then 80 columns is fine (Score:2)
Oh yeah, forgot this bit of nonsense. This is also either a case of not knowing what your text editor can do, or of using a _really_ crappy text editor. Your text editor should have a mode where you can display spaces & such, and you can _very_ easily tell the difference between spaces and tabs.
That this conversation is evening happening is amazing to me - how can so many people not know about the tab issue by now? How are
Re:More then 80 columns is fine (Score:3, Insightful)
not really (Score:2)
Re:not really (Score:2)
Tabs ARE a character, and should be TREATED as a character (since they ARE). Therefore, the emacs way is fucking idiotic, and the vi way is correct. I've never advocated one over the other for any other reason, until now (I hate the interfaces of both programs, so it didn't matter to me before now; UI-wise, they both suck pr
Re:not really (Score:4, Interesting)
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:not really (Score:3, Informative)
Re:More then 80 columns is fine (Score:2)
Conventions are for the READER, not the author (Score:5, Insightful)
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 (Score:5, Funny)
Oh, my God, I wish I was joking.
Re:Conventions are for the READER, not the author (Score:2)
Sam
Re:Conventions are for the READER, not the author (Score:3, Interesting)
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
Re:Conventions are for the READER, not the author (Score:2)
I've tried that on two occasions in the past and talked to others who have had their own first hand experiences. Invariably, the reformatters tend to handle some conventions better than others and having everyone adjust their editor's settings to the team's conventions is a lot simpler for
Re:Conventions are for the READER, not the author (Score:2)
Stuff like:
foo () {
some really long line
}
becomes:
foo ()
{
some
really
long
line
}
becomes:
foo() {
some really
long line
}
or whatever.
It's a pain in the arse.
Re:I don't think so (Score:3, Insightful)
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 ev
Re:Conventions are for the READER, not the author (Score:3, Insightful)
It is well and good to have a sandard format that everyone agrees to read and represents the format in which source code is maintained in the source code repository.
However, when writing code, it is a real hinderance to be forced to format things in a manner to which one is not accustomed. You spend too much time worrying about how to indent large function call actual parameter lists, long chained pointer indirections (i.e. foo->bar->entryIndex].reference->lookup[lookupInd e x * loo
Re:Conventions are for the READER, not the author (Score:2)
Re:Conventions are for the READER, not the author (Score:4, Insightful)
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 (Score:2)
I agree. To my mind, the only thing worse than no conventions are conventions that get in the way of effective development. Your polymorphism example seems particularly egregious. In order to prevent something similarly annoying, our documentation standard leverages javadoc, which since the 1.2 jdk, allows for the inheritance of
Re:Conventions are for the READER, not the author (Score:2)
Yeah, that works fine except that when translating your crack-induced style to the normal form and back again screws up revision control diffs, thereby making them completely useless.
Also, your little rant about documentation basically boils down limitations in tools. Javadoc since 1.4 (1.3, maybe) automatically p
Re:Conventions are for the READER, not the author (Score:2)
Re:Conventions are for the READER, not the author (Score:2)
And it's even more important if you'd like your code to become the basis of a successful open source project. By "successful," I mean "with code contributed by more than just you." While I think formatting beyond 80 columns reduces readability, there's a lot more to it than that. Everyone in my office adheres to the Indian Hills C Style Gui [chris-lott.org]
Re:Conventions are for the READER, not the author (Score:2)
How old are you? (Score:2)
Let me put it this way. Let's say that I'm a prospective employer. I'm looking for someone with a good head on their shoulders, that works well with a team, and can adapt to new situations. Then I hear you say the above statement. So far, what I know of you is that bracing style is a religious doctrine for you, you will not respect
Re:Conventions are for the READER, not the author (Score:2)
Use indentation, not braces: The braces are probably going to be pushed off the bottom of the window for long functions/methods whatever, and your brace style just make this problem worse.
Re:Conventions are for the READER, not the author (Score:4, Interesting)
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:Conventions are for the READER, not the author (Score:2)
If a person cannot bring themselves to conform to the team's conventions, then yes, they cannot work there.
Here's the REALLY BIG HINT all over again. If "the best coder ever" can't get along with the rest of the team members, they aren't the best coder for our team.
The best way is to be adaptable and realize that the exact conventions don't matter. If it takes you more than two days to adapt to new convent
we stick to 120 (Score:2)
A) pretty much all editors support more then 80 columns, and if you want to use an old version of VI that can't do mroe then 80, it's not really yopur right to enforce your unwillingness to stick even remotly code to the state of the art on everyone else.
B) most programmers have a screen roughly in the 1280x1024 category, an
Re:we stick to 120 (Score:2, Insightful)
A solution? (Score:2)
It's still hard to read, but hey, it'll fit in 80 cols in emacs just fine now.
Cry me a river... (Score:2)
But really... is the 80 column limit that important to you?
You know that you can bump up the number of columns on console displays, right?
Read here [linux.com]
There are also a number of tools [faqs.org] available to put code in a form that you find agreeable.
People still print code? (Score:2)
Having said that though, I just started my first project where the 80 columns limit was specified. The customer, who writes some of the code for the project, does still print code. So, I'm finally limiting code to 80 columns.
Re:People still print code? (Score:3, Insightful)
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.
I miss 80 colums (Score:2)
That assumes... (Score:2)
Whoah there, all you folks who are about to reply questioning my eyesight, my coding abilities, or my sanity! Yep, I know what I'm doing. Yep, I've used 'vi' till it's come out of my ears (don't ask), and it's cool for certain types of editing. But I find that monospacing tends to give undue emphasis to small punctuation marks, and generally makes code far harder to read at a glance. I know code doesn't look
Re:That assumes... (Score:3, Informative)
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.ht
Readability (Score:5, Informative)
Some random "web development" site [webstyleguide.com]
Scroll down a bit to get to the chars per line bit [managedcaremag.com]
All of these basically agree that more than 80 chars per line is quite hard to read.
Solution (Score:2)
Code is not prose (Score:2)
Show me a study that compares code at 50 columns, 80 columns, 132 columns, and 200 columns and you'll get my full attention.
Also of note: the first link which advocated shorter line lengths is on a page with unlimited line length.
Re:Code is not prose (Score:3, Insightful)
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
Geeks are too anal (Score:2)
E-mail (Score:2)
A good e-mail program will properly wrap text to fit within these limits (specifically thunderbird comes set by default to wrap to 72 columns). If p
well-known saying... (Score:4, Funny)
80 Columns is STILL a reasonable rule (Score:3, Insightful)
My observations... (Score:3, Insightful)
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.
Re:72 (Score:3, Interesting)
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:72 (Score:2)
Re:72 (Score:2)
(I have actually used IBM punch cards, and I still have a few souvenir cards hidden away in a drawer.
Of course, this relic isn't nearly as amazing as the US railroad gauge. (Not to mention the myths about where it came from [snopes.com].)
In any case, I'm frequently bemused by email and newsgroup messages that, in their multiple levels of quotes,
Re:72 (Score:2)
and want line numbers displayed, you lose 8 columns to the numbering (at least
in vi(m)).
That's why I code to 72 when I can (pretty easy in C and Python...impossible
in C++ or Java).
Re:72 (Score:3, Informative)
Re:I'm sorry... (Score:5, Informative)
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).