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

[saden1]

The current project I’m working on has set 120 columns as standard acceptable column width. This is of course the maximum characters you can print on an A4 paper in landscape layout.

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

[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.

Re:U of Toronto

[julesh]

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?

huh?

[reynaert]

Why would vi have any problem with long lines?

Re:huh?

[Rheingold]

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

Terminal too wide

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.

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.

yes it does

[jeffy124]

when printing a monospace 12 point font on a piece of paper.

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.

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.

Re:The Way of the World

[AltaMannen]

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.

Re:The Way of the World

[eraserewind]

Auto-concat is not guarenteed to be correct, how can a system know which lines definitely should be joined? It can only guess by using some arbitrary rules?

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

[ComputerSlicer23]

You're doing a very bad job of interepreting his words, so I'll give you an example:

1. Item #1
2. Item #2
3. Item #3
4. Item #4

Now, that would look just stupid if it was like this:

1. Item #1 2. Item #2 3. Item #3 4. Item #4

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

Re:The Way of the World

[Halfbaked Plan]

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.

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:I don't get it

[Vaevictis666]

I guess that's part of the reason some of the newer languages out there (Perl, Python, Ruby) allow post-conditionals.

die("The meat of the statement is at the front of the line") if Language.supports("post-conditionals");

Re:I don't get it

[hotpotato]

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.

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

[E_elven]

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

Re:I don't get it

[__david__]

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

Re:I don't get it

[Scarblac]

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.

Error

[Anonymous Coward]

With most people using X

The proper technology name is ActiveX.

80 columns lives

[bandy]

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.

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.

Re:It's been dead a long while.

[chris_mahan]

Use Jedit.

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

[monopole]

...Hollerith cards

Never!

[Dr. Photo]

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

More then 80 columns is fine

[stefanlasiewski]

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!

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

[E_elven]

The problem with tabs is getting things to align neatly, particularly for functions and such. I like to align my function arguments (if need be):

some_function(parm,
other_parm,
one_more_parm);

Hard to do with tabs unless you mess with the whitespace around the parentheses which isn't a good idea.

Re:More then 80 columns is fine

[Anonymous Coward]

The problem with tabs is getting things to align neatly, particularly for functions and such. I like to align my function arguments (if need be):

some_function(parm,
other_parm,
one_more_parm);

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

Re:More then 80 columns is fine

[Mr Z]

To fix the formatting: GNU indent

To print it nicely when you're done: vgrind

You're welcome.

--Joe

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

[jc42]

I've written scripts and/or aliases to do just this on several projects. Somehow, the code-format nazis never seem to appreciate it.

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 can see on the screen at once. Wasting a line to hold just a brace can materially limit what I can work on.

If someone with vision limitations wants to read my code, I'd encourage them to reformat it however is best for their eyes.

And in most languages, if your code can't handle this reformatting, there's something wrong with it. Canonicalizing it to a standard format shouldn't effect anything but its surface appearance.

There are a few languages for which this isn't quite true, of course.

Re:Conventions are for the READER, not the author

[renehollan]

I call bull.

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[lookupInde x * lookupIndexScale + lookupIndexOffset].Value), rather than coding.

The solution is to use a pretty printer program that is sophisticated enough to understand and generate the source repository form, and automatically reformat to the tastes of most developers.

People were meant to code, not worry about indentation-nazis.

The worst part of coding standards is when they are so poorly thought out that they make it impossible or at least very difficult to write certain syntactically-valid programs. This usually crops up when internal function documentation standards do not provide for non-fundemental types for parameters or require that their types be documented fully. It creates havoc with polymorphic impementations of different specific derived instances of an abstract base class: you have to repeat the function parameter type documentation over and over and over. Change the class and you have to update documentation in each implementation file. Code nazis I've encountered retort, "So? Don't use polymorphism. Newbie developers don't understand it anyway." The right answer is to encourage use of Javadoc, doxygen, or other tools to make the synchronization of code and internal documentation easier. C# supports this notion natively.

But no, instead Mr. Code Nazi effectively takes away one of the most powerful OO concepts because some weenies "don't understand". Tell the weenies to slog fries at the local burger joint until they get a clue.

The rules by which I like to code are (a) read anything formatted reasonably; (b) format new code I create any damn way I please (within reason -- I have to maintain it too); (c) defer to the style already present when maintaining legacy code.

For all your code-nazi bluster, you're screwed when you decide to leverage some open source code that uses a different style and there's the possibility you might contribute your changes back to the official code base (you don't have to if you don't distribute your modified version). I suppose you can make "exceptions" for foreign code, but why shackle your own developers and not shackle outsiders? Seams ass-backwards to me. (Of course, the real reason is "because I can and it makes my code-nazi job look important).

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:Conventions are for the READER, not the author

[Mr Z]

I find tools like GNU indent to be handy for fixing grossly misformatted code. I don't like what they do to the subtlties of good code formatting.

For instance, suppose I'm doing the same operation with different parameters. Something like this (with periods to show the spaces):

some_funky_api (10, . 5, . .11, . 3);
some_funky_api ( 3, 113, MAGIC, 114);
some_funky_api ( 0, . 0, . . 0, . 0);
some_funky_api (33, .33, . .33, .33);

Now what happens if I run this through the typical code autoformatter? I get something like this:

some_funky_api (10, 5, 11, 3);
some_funky_api (3, 113, MAGIC, 114);
some_funky_api (0, 0, 0, 0);
some_funky_api (33, 33, 33, 33);

You see, sometimes you can subtly format your code such that the physical layout highlights the similarites and regularity of the code, and the text that remains highlights the differences. (Also, tools like "rectangular cut-n-paste" work well with code like that....) Automatic reformatters don't see that subtle layer of structure and destroy it.

That's why I'll only use them as a phase of cleaning up some horribly tab-damaged sh*t.

--Joe

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:we stick to 120

[ezzzD55J]

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

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:um news flash

[0x0d0a]

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.

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

Re:People still print code?

[Dan Ost]

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.

Re:That assumes...

[Dan Ost]

You should try Donald Knuth's CWEB environment. It combines coding and
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.htm l

well-known saying...

[Polo]

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

Re:72

[joeljkp]

Or if you write a lot of Fortran77 code (common in engineering).

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:not really

[More Trouble]

You might be interested in the Unix commands "expand" and "unexpand".

:w

80 Columns is STILL a reasonable rule

[mystran]

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.

Re:Code is not prose

[rangek]

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.

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

Also of note: the first link which advocated shorter line lengths is on a page with unlimited line length.

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.

Re:72

[ffsnjb]

72 column is required in most COBOL environments I've worked in. *shudders*

Actually, I should put COBOl experience on my resume, I could probably score a really badass job with that. All of the old COBOL hackers are dying. Someone has to port that legacy code eventually.

Re:I don't think so

[mike_sucks]

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.

My observations...

[bziman]

What I've noticed, is that the more efficient coders on the team (myself included) need to be able to look at multiple pieces of code and documentation and applications simultaneously. Therefore, we have vi and terminals set up with an 80 character limit, so we can fit two windows side-by-side on the desktop.

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.