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....
Why would vi have any problem with long lines?
but I really had no idea that you were supposed to limit to 80 characters. I skipped intro to cs as an undergrad (thanks AP Comp Sci), so I never had someone deduct points for not following this particular rule, and no one since has asked me about it.
considering that i hardly ever am in a console session where i have only 80 characters accross.... no, i care not about 80 char alignment. even when i dont load up X, i still use the fb to get a decent sized console to work in. 80 chars is just too narrow for me these days
I was taught to use a 72 character limit on an 80-wide window. I can't say I've looked much at other people's code lately for comparison.
The only thing I hate more than hypocrites are people who hate hypocrites.
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.
sing the framebuffer thingy I get a 1280x1024 command line, so I get miles of columns for code. surely now this can be used instead of crazy vt100 or whatever
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.
...people don't follow stupid rules like this.
Back in school we used to have to write the whole program out on paper first, that was a f-ing joke.
I have never written code with pen and paper;
I may write ideas & conditional statements, but never code.
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.
Only 'flamers' flame!
Does slashdot hate my posts?
With most people using X
The proper technology name is ActiveX.
80 columns is still the default width of an xterm and Gnome Terminal window. Grumpy cow-orkers insist on sticking to 80 columns. It's a fact of life. Get used to it.
"You might as well get your son a ticket to hell as give him a five string banjo." -unknown minister
Printing wide code can be annoying - although if the printout showed when lines wrapped with the down-then-left arrow common in some editors... that would make life easier.
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!
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!)
...Hollerith cards
Well, I guess I came to the party late. I didn't even realize that code used to be formatted to 80 columns!
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 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 begin to adopt fixed-width as well and see if I can continue to make code maintenance improvements. To me, computing speed is no longer an issue. Development and maintenance speed is king now.
Ruby on Rails Screencast
If we don't format our code to 80 columns, then how will we maintain back-compatibility with IBM punch cards?!
I rarely keep program windows as wide as the screen, since I want :)
to see parts of the other windows I'm using at all times. Don't ask
me to use taskbars and such - I just don't like them
My code typically ends up somewhere around 80 characters wide,
at most, because of this. And it's no big deal putting that in PRE
tags or similar on the web if it's already formatted.
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!
"Can of worms? The can is open... the worms are everywhere."
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
Here is the realistic situation. 80 columns was created as a formatting standard because of punchcards. Mosto fthe people I know have moved to 120, with the following justifications:
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, and it is a benefit to be able to *use* the extra real estate
C) 120 works fine for printing in landscape.
- The unexamined life is not worth leading -
It's still hard to read, but hey, it'll fit in 80 cols in emacs just fine now.
This sig no verb.
Yeah yeah... this is gonna sound harsh...
:)
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
There are also a number of tools available to put code in a form that you find agreeable.
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.
But on a 1200X768 monitor, 80 columns is only about 1/8th of the screen in a readable font- I prefer 132 column limit these days.
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
80 columns are the devil! Why, my :-)
Osborne uses 52 columns and the ][e
uses 40 columns. Everybody should
reformat everything to 40 columns now,
lest they jeopardize cross-platform
compatability
AND EVERYBODY SHOULD USE ALL CAPS
BECAUSE NOT ALL MACHINES CAN DISPLAY
LOWERCASE CHARACTERS!
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 exactly like English text, but I seem to read them in a similar enough way that similar layout works well for both.
Of course, I know I'm in a minority, so I don't expect everyone else on the project to do the same. But the important thing is that if the code is well formatted, you should be able to read it in whatever editor you prefer, in whatever font, with whatever other preferences. If you're laying out your code to match a particular editor, IDE, or whatever, then you're adding a dependency, and making it harder to switch in future.
But then, even with a monospaced font and an 80-character window, what's the major problem with the occasional long line? Any decent editor will scroll or wrap it for you, so following the needs of the code shouldn't cause that much inconvenience. (And if it does, you're probably using the wrong editor!)
Ceterum censeo subscriptionem esse delendam.
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.
I think this issue is really about how geeks love to create rules for everything and think everyone should follow their lead. Don't we have enough functional bugs in our code to worry about without finding additional ways for code to be defective (layout, column limits, naming conventions, etc.).
Using 80 columns is still very important (in my mind at least) when it comes to e-mail. Due to the differences in readers, wrap styles and so on it quickly becomes an issue. When was the last time you got something where the replys quickly screwed up and shattered something readable into a mess of short lines and quoted symbols stuck in the middle of sentences?
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 people are using HTML e-mail though... well, hell, they're already wrong to begin with.
Um, no: http://www.jwz.org/doc/tabs-vs-spaces.html
There are plenty of people who write code longer than 80 characters per line. They're called "assholes".
[o]_O
It's well known that the saying "80 column mind" means that you're narrow minded. Google it. :)
Why argue when you have this?
16? With all of the choices available to code with -- languages, libraries, operating systems, compilers, etc. -- your main gripe is bracing style? Are you fucking kidding?
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 any preferences but your own, you will waste time bitching about a coding style instead of getting work done (the "spit fire" comment), and you expect that a codebase could or should have more than one coding style in it -- that or "my way or the highway."
Most employers want someone who works well in a team. "Team" usually implies working together toward a common goal. It requires some uniformity in process. But you aren't even willing to be swayed by something as trivial as bracing style. You probably have an enormous opinion of yourself and yet cannot adapt to a perfectly valid and trivially different coding style.
Nice.
The sad part is, you're useless to both commercial and Free Software camps. Commercial software won't like you for the above reasons. Free Software projects all have different idioms and coding guidelines. Imagine their chagrin when some hotshot comes in and starts spitting fire simply because of bracing style.
Grow up. Learn to adapt.
- I don't need to go outside, my CRT tan'll do me just fine.
All of those studies you referred to are speaking of prose. If anything, they speak to having 80 column multi-line comments.
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.
- I don't need to go outside, my CRT tan'll do me just fine.
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.
Line wraps are a no-no for us. The 80-col limit is respected because it makes everyone's life easier.
At least, for code.
That's the width I find most comfortable for Objective-C, where
method names can get pretty long, and things get pretty ugly
sometimes when there are nested method invocations.
for example:
[[[textView layoutManager] textStorage] setAttributes:(NSDictionary *)attributes range:[highlight highlightRange]];
(and that's just what I was able to come up with quickly. It can be longer than that.)
Such statements can be broken up over separate lines, but that can get ugly too. Sometimes it just is better to let something take up 100-110 characters.
Both personally and as part of the standard coding conventions at work.
I want SOME standard for how wide my windows have to be to see it all, and it's a pretty reasonable one.
Remember, the linux kernel is based on 80 characters and 8 space tabs. "If you're running out of room, your code is nested too deep. Refactor it."
Because the same formatting rules are always used when checking IN to source control
Jim writes:
foo ()
{
some
really
long
line
}
which gets checked in as:
foo () {
some really long line
}
which Jo checks out as:
foo() {
some really
long line
}
modifies to
foo() {
some really
long line
that works
}
but gets checked in as
foo() {
some really long line that works
}
Any part of the source control tools that pull code from the repository needs to apply the current users rules, this implies the diff tools as well.
Sam
blog.sam.liddicott.com
Bracing style can be enforced by a fscking script.
It should not be the task of a programmer to adhere to a pointless punctuaction and bracing style, that is a presentational issue better addressed by automatic tools ( once a program is syntactically correct).
IANAL but write like a drunk one.
And only finished versions of the code.
The differences are applied to the original, finished version of the code, not to the one generated for readability.
IANAL but write like a drunk one.
These days, 17-inch monitors don't cost significantly more than 14-inch ones,
and 19-inch ones are very reasonably priced. Consequently, it's possible to
use resolutions higher than 640x480 without being forced to squint. As a
result, you can fit more than 80 columns in an editor and read it comfortably.
There are obviously still limits on how wide your code can be without causing
people problems viewing it, but I would say the limit is a bit more than 80
characters these days. Probably at least 100, if not 120. In any given
workplace, you should get your programmers together and agree on a limit.
Cut that out, or I will ship you to Norilsk in a box.
Coding conventions are for you and those who maintain your code - from now until Doomsday.
e rs()]),that->Fillup(aLine))
Where practical, I stick to 80 columns so I can email and print upright in the default font.
With VeryBigMethod->Names(With,LotsOf(Complex[*Paramet
or when using coding conventions such as highly-nested "if" statements, this isn't always practical.
At that point, I shift to whatever will fit on the screen and on a landscape printer, but no more than 132.
The bottom line:
Coding conventions as a tool, but when a tool outlives its usefulness, it's time to replace it.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Is using vi in the first place. For a quick edit use pico, nano or joe. I like nano because you can jump right to a line number.
Only the State obtains its revenue by coercion. - Murray Rothbard
What 80 column limit? I have been writing commercial software for about 20 years now and I have never used an 80 column limit.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
As someone else said, it allows vim (at 1600x1200) with vertical window splitting to simultaneously show 3 (at times 4) whole full-length buffers at once. Oh so useful.
Also, I have Computer Modern TT set up in vim. Yummy. I've always loved how anything formatted in TeX looked just gorgeous, and now I code in it.
horizontal scrolling? that would be a pain but i cant see any other way. vi with line wrapping could get painfull pretty quickly. think of those long functions indented more than 5 levels. maybe an editor/display that simply has a number counting the tabs or whitespace. could go well with python....
patent rant mode on
p.s. heres publishing before some dooky head goes running off to the patent office! yes, its trivial, but the patent office seems to be pretty brain dead these days as to whats obvious...and yes, using a color instead of line is also obvious.
Stop reading here. There are no useful comments in this whole thread.
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.
I browse with 80 Character Limit /w lynx. =)
Am I the only one who gets grumpy
No!
I like to indent my C code using the GNU style and it does go in a ways sometimes.
But my co-developers, first they do when they open up an Emacs on our application is to stretch the damn right margin out to fucking infinity.
Thereafter, everyone must do the same or be confounded with crap due to weird wrapping.
Email has suffered this way recently, too.
"Provided by the management for your protection."
In Sol 8 the stock vi lets you go up to 163, I tend not to go over 132 so it's safe for me. I've found 132 is safe for many of the stock distributions.
-M
I've got an IBM mainframe over here running MVS that insists on 80 columns.... Not all these old computers are dead.
... i still code on a typewriter!
Try using "expand -t 4" and then edit the file as normal (if you want to convert to an indentation level of 8, try using indent, astyle or cb). However, I should caution you that "unexpand -t 4" does not understand the difference between whitespace and a string literal in C, so you should not use it to convert from spaces back to tabs (it can ruin your day to get random tabs in your printfs). Instead, try using something like "indent -ts4" (warning: indent can produce very ugly results if you don't study the options carefully, and it can also totally screw up your diffs).
p.s. I normally advocate strict adherence to the 8-character tab standard, but sometimes it's better to just appease your co-workers by pretending to use their 4-character standard Most people these days use 4-space indentation anyway (i.e. tabstop=8 and shiftwidth=4), so there's no real difference other than the encoding method.
agreed on team 'indent' style
set up personal indent style
set up vim macros
so that read in file, apply personal indent macros
edit
save, insing macro which applys team ident style
Missing poll option:
I use 480 column windows on my 3840x2400 LCD monitor and Quadro FX3000 video card. 10-point Monaco, baby!
My Other Computer Is A Data General Nova III.
Actually, I don't think there should BE a column limitation of any particular size. Just as one would set what indentation display for tabs, so too should they set whatever wrapping (if any) they wish.
It's like Burger King - I want it my way (only I don't want it to taste like ass), and I want others to have it their way, too. With properly-designed software, this shouldn't even be an issue anymore.
My Apple //e shipped with a native resolution of 40 characters. My grandfather had an 80-column addon card, but as the display is a TV-screen, 80 columns was fuzzy. I still use my //e, as a dumb terminal off my linux box.
This post written under Gentoo-linux with an SCO IP license.
Yes yes! Best argument yet for why super long lines are good. I do that all the time and scrolling is a penalty I happily pay.
And yes, code and text are entirely different and are read differently. Code works best when kept on a single line as much as possible. The dreadful K&R style so thoughtlessly propagated by typical Unix programmers was chosen strictly because it enabling typesetting to work better in a small book. Looks like crap! What's with the stupid open brace on the same line rather than on its own? It was done simply to make the book cheaper to publish!
See, kids, this is what happens when you reply to a 12 day old message without first reading and understanding the rest of the thread. Take notes - there will be a test later!