While coding, how many columns do you format for?

Question

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?

Answer 1

79 columns.

Answer 2

120 columns.

Answer 3

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

Answer 4

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

Answer 5

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

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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

Answer 10

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

Answer 11

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.

Answer 12

I have my right-side guideline set at column 90

Answer 13

80 - The one true width...

Answer 14

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.

Answer 15

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)

Answer 16

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.

Answer 17

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.

Answer 18

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: http://novicecoder.com/ides/visual-studio-margin-guide-lines

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.

Answer 19

132!

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

Answer 20

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.

Answer 21

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

Answer 22

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! :-)

Answer 23

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?

Answer 24

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

Regards, Ollie

Answer 25

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

Answer 26

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.

Answer 27

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.

Answer 28

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.

Answer 29

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.

Answer 30

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

Answer 31

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.

Answer 32

120 for development.

1024 for compressed production.