in the old days everything was 80 columns. so if you wanted your code to be readable, you'd make it fit. but that's not the case anymore with wider and wider screens, so how long of line is too long?

+1  A: 

79 columns.

Ben Hoffstein
+10  A: 

120 columns.

+1! I was starting to think it was just me who liked it wide...
Stu Thompson
120 is the new 80.
All my header comments are in 120. ;)
Talvi Watia
+1  A: 

80 if I actually try. If not, whatever runs off the screen, ~100-120

+2  A: 

132 columns, usually, although for a lot of stuff done in Visual Studio I tend to lose track of columns and format for the editor window. IIRC there are VS add-ons that add a nice marker line so you know when to wrap, however...

Chris Charabaruk
+1! I was starting to think it was just me who liked it wide...
Stu Thompson
Visual Studio has column guides without any add-ons, although enabling them involves messing with the Windows registry.
Adam Rosenfield

In times of good IDE's, I never thought of that before: I let the IDE handle this Issue (or Addins for the IDE)

+49  A: 

I still try to stay under 80:

  • With my widescreen it lets me put 2 files side by side
  • It's readable when I print it to paper
  • It's less likely to wrap when I post code to a newsgroup or forum.
Exactly the reasons I have. Guess I don't have to post an answer. :)
Additionally, i think 80 is an optimal length for fluid visual navigation. Very wide lines of text that needs to be comprehended line by line can, at least for me, be more difficult to follow. That said, i typically view code in an IDE which uses my style rules.
+4  A: 

The thing is, I prefer thinner code still because I tend to turn my widescreen monitor on it's side to get more vertical real estate and be able to read more of the code at a time. 80 is still a good number in this case. But when you consider the fact that most code still doesn't break that barrier, widescreen monitors really are a waste for programmers unless you can get that vertical space.

Chris J
+7  A: 

I don't worry about it. If you're cramming as much code as you can on one line then you're already doing it wrong.

Disclaimer: I have a wide-screen monitor and no printer :)
+4  A: 

76, that way the line + line number can fit in a standard terminal window.

John Millikin
+1  A: 

Usually 80. Code is easier to read and understand when it's narrow.

+3  A: 

80, out of custom. It's also fairly practical -- I find my eyes can't scan 132 columns of code as easily as 80. With 80 I can focus on the middle of the screen and scroll and have a reasonable chance of spotting what I'm looking for. With 132 I scroll WAY slower and have to scan my eyes back and forth.

If you're looking for something specific, I don't know why you wouldn't use your editor's "find" feature instead of scrolling through and skimming the code -- this should work in most cases. If you don't know the precise name of what you're looking for, a class browser might help you discover that.

I have my right-side guideline set at column 90

Mark Cidade

80 - The one true width...

Steve Lacey

When I am caring, I code to 80 columns. I use a number of things to try and do this, including the "line" that others talked about on the UI. It also helps me put two codes side by side in a wide-screen which is nice.

When I don't care, it is just ad-hoc, whatever my terminal or editor has on the end of the screen so it doesn't run over to the next line without being poorly formatted.


Ideally... never, as in jedit which offers word wrap

That is one option bitterly missed in eclipse from a looong time ! (since 2003 in fact)


78 columns. Although I do allow stuff to run over occasionally if it makes sense and improves readability.

It doesn't really matter what you pick, as long as you choose something that isn't huge, and stick to it. Having a fixed column width to your code forces you to avoid some of the nastier things that can happen otherwise, for example: embedding massive strings as one huge line, when you should really do doing something else with it, or stopping you from going nuts with hugely complicated algorithms, avoiding huge ugly nested ternery operations, and helping you convince yourself that factoring out complicated stuff into temporary variables is a good idea..

I chose 78 columns simply because it means you can chuck code directly into a plain-text email, and have it survive one reply.

+3  A: 

I try to format for clarity, not a spesific column count. You know, line up semantically or functionally related things and so on. Whitespace is free, so use it!

The comments above about IDEs ring true as well, if you can't see the code you´re working on, take a look at your tool first.

Internet Friend
+2  A: 

I try to keep my line width so that on the rare occasion when I print it, the lines all fit within the width of the page. I determined the value by printing a line of "1234567890" repeated, and seeing where it wrapped.

This tip shows how to get Visual Studio to put a light marker line so you know when you've gone too far:

I use it as a guide rather than a hard-and-fast rule.

Edit: I use 90 columns, based on the printer font Lucida Sans Typewriter at 10 points.

Mark Ransom


  • I like to indent for each level (method & member declarations are in 1 indent in a class),
  • I like to see lots of code on the screen,
  • I have a somewhat peculiar desire (although not unheard of) to format code sorta COBOL-esque

...which all means many columns.

Stu Thompson
+1  A: 

I don't really bother consciously, although if I'm working with an API that has methods with long parameter lists, I may deliberately break up the list for better readability. I also tend to with long strings in VB.

Bob King
checkstyle keeps me straight.
Stu Thompson
+4  A: 

I do 120.. 80 is much too small and I end up wrapping text a lot. 120 seems good; especially since most people have big monitors

Corey Goldberg

I have set edge.column=100 in SciTE, although it is quite arbitrary. Sometime I let go a bit beyond that, but I try to stick to this limit. 80 columns is a bit obsolete (old size of terminals) and perhaps too small, beyond it can wrap when printing or such. Depends on settings, of course. Beside, with the font I choose for most languages, this margin nicely go just on the right side of my editing window, with the size I have set by default to my editor application. Which allows two windows side-by-side. So it isn't so arbitrary, after all! :-)

+13  A: 

I see a lot of people saying they format for 80 columns. While it may be true that narrower code is easier for some people to grok (personally I let my lines run as long as they need) I don't see the need for an 80 column limit.

I understand the legacy reasons for picking 80 columns, but are they relevant today? Does anyone actually code in an environment where they can't configure their editor to show more than 80 columns at a time?

So why not use 60 columns? 100 columns? 80 seems so arbitrary to me... it's based on a legacy technological limitation that we've long since overcome. Why not figure out what the optimal line-length actually is?

I think 80 is actually about right. Forget about current technology and imagine you have an unlimited screen. You still want to impose a limit such that you can look at editor frames side by side without a sea of whitespace in between them. I think 80 accomplishes that well.
In print (e.g. books, not code) the optimal line length is generally considered to be in the range of 45-75 characters, depending on various factors. Code is of course different, but this gives us a place to start. 80 characters probably isn't a bad guess, and I wouldn't want to go much longer.
Steve S
I do it just because having a point at which to wrap is good for code readability, and since the standard of 80 already exists, why deviate?
Because no one programs in VGA text mode any more? There has been improvement in screen size and resolution recently, didn't you notice?
+2  A: 

80 or 120 depending on the project I'm involved as we have different coding guidelines.

Regards, Ollie

Oliver Gierke
+3  A: 

IDE guideline at 120. 80 is very hard to read Java code for me.


I used to use shorter lines, but with the addition of Linq to C# which promotes fairly long functional lines, and the fact that I'm coding on a 24" widescreen monitor, I have the column guide set to 180 characters (yes, 180).

I don't tend to use all of that all of the time, but I don't find it hurts readability at all, and if the space is there you may as well use it.

Greg Beech
+1  A: 

Everyone on my team has two 19-inch monitors at 1280x1024 resolution. We all code in a maximised window, and manually wrap anything which would go offscreen. With this setup, that's around column 160.

+1  A: 

Eighty characters used to make sense back in the days of daisy wheel printers, which is where the standard originated from. I have worked in a few shops that still enforce it as a standard, although we do not currently have an 80 character limitation.

What we do have now is a 120 character recommendation. With our current IDE settings, we have determined that this works very well for us. For printed code reviews, it still fits comfortably on legal with ample room to the right for comments.

The recommendation allows for both comments and code. When code is encountered that has reached, or nearly reached, the 120 character recommendation, it is a clear indication that there is probably a need to refactor that line for whatever reason it has grown to that length. We strive for short and narrow methods, meaning that the lesser the number of columns used, the better the chances that we aren't deeply nesting, over-qualifying calls, etc.

+3  A: 

I stopped manually wrapping a couple years ago. It's an attempt to anticipate a future user's window size, tab stop setting, etc etc, and as such is guaranteed to fail. It's the kind of problem that situationally adaptive technology should be solving instead of programmers' time being wasted on it.

Personally, I have no problem visually processing wrapped lines of code, and I find the "eww" reaction some people have to them to be kinda prima-donnaish. But that's me being a bit judgmental.

+3  A: 

I set IDE column width to 9999. I think this whole question has a stench of green screens and cobol.

+1  A: 

In my experience, reading source code is nothing like reading a book or other literary work. Even if we ignore line-lengths, source code is generally formatted in a much different manner than literature. Therefore, I see little point in referring to literary standards when specifying code formatting requirements.

Reading code follows a pattern something like:

  1. Identify the overall structure and flow
  2. Identify sections of the code which are of interest (based on identifier names and comments)
  3. Analyze sections of interest with a situation-dependent level of scrutiny

To me, seeing the big-picture flow (which is generally expressed vertically) is more important than horizontal "readability" of individual lines. Breaking up a statement into multiple lines simply for the purpose of following a line-length rule can be counterproductive since it:

  1. results in a vertical expansion of the code so I can see less of the control flow at once
  2. breaks up the visual unity of a (vertical) sequence of instructions
  3. gives that statement more visual significance (more vertical screen real estate) than it might warrant

Screens are wide, scrolling is easy, and most humans do not speed-read source code (I don't understand the eye-scanning concern). Therefore, there should not be a specific limit on the length of a line -- it should be up to the discretion of the developer based on what he feels best expresses the flow from the standpoint of a human reader.

Printing, emailing, and speed-reading are special-cases that may require manual or automatic reformatting (many such tools exist). I wouldn't want to structure my code differently to optimize for those cases.


120 for development.

1024 for compressed production.

Talvi Watia