Maximum line length of your IDE / checkstyle

Question

Duplicate of

• Coding standards and line length
• What is a sensible maximum number of characters per line of code?
• Line width formatting standard
• When writing code do you wrap text or not?
• Is there a valid reason for enforcing a maximum width of 80 characters in a code file, this day and age?
• Where to wrap a line of code, especially long argument lists?

My team standardizes on 80 characters as the visual line margin limit on our IDE and checkstyle as well. I think 80 chars was the standard when people used to code using 640x480 monitors back in the 1950's.

With the advent of large screen monitors (my team of 12 developers currently use double 19 inch 1280x1024 res screens), I think the 80 char limit should be increased. Checkstyle by default uses 80 chars.

Is there a movement toward a larger char limit within the programming community? Is there even a standard....or is it purely arbitrarily set by your PHB (pointy haired boss) ?

Answer 1

FWIW, I don't think the 80 character limit is bad at all, even in these days when many people have huge monitors to handle it. Text (be it in a natural or a programming language) just becomes more difficult to read and make sense of as lines get longer.

Answer 2

80 characters is what can be printed out on paper without wrapping. I used to set it to 80 characters, but after going a couple years without doing an on-paper code-review, I switched to 100 characters for the reasons you give. I find this is better especially when using languages like C#, since you're already 3 or 4 tabs in by the time you are actually writing code (indent from namespace, indent from class, indent from function).

If you're still doing code reviews on hard copy, you'll want to stick to 80. Otherwise there is no reason not to increase the limit, within reason. Do exercise some caution though, a single line of code spanning your entire large monitor is probably not that readable.

Answer 3

Wider monitors aren't any excuse to create more convoluted, impenetrable code. A width limit keeps you conscious of how long and complex your lines are getting.

From the Linux coding guidelines:

Now, some people will claim that having 8-character indentations makes the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program.

and

Functions should be short and sweet, and do just one thing. They should fit on one or two screenfuls of text (the ISO/ANSI screen size is 80x24, as we all know), and do one thing and do that well.

If you have a wide monitor, go for a multi-column view or some such.

Answer 4

It's not a hard & fast rule, but we take the approach that if you're constantly hitting the 80-column limit in your code, it's time to refactor.

Answer 5

If you are printing then I think that 72 characters is a better limit, but I prefer about 80 characters, as I can split long lines to multiple lines, which will make it easier for others to read. Long lines are harder to understand, but if you break a long line into smaller sections then it is easier to see quickly what is going on, IMO.

Answer 6

Here's another vote for the 80-character limit. As most of the other comments have pointed out, 80 characters is the practical limit for printing and deeply indented code usually means that it is time to refactor. Here's one other thing to consider... even with wide-screen and multiple monitors, it is sure nice to fit multiple full width windows side-by-side. This is especially true if you have to read side-by-side diffs.

Answer 7

No, I've not heard of such a movement.

Personally, I prefer the 72 character limit, for several reasons:

• looks good off screen (on paper)
• easier to read (there was a study about this in the publishing business)
• can be viewed paralell with another one, or two windows (for purposes of diff)
• although there are fine editors today, I don't want to rely on their wrapping options (or any other) in my attempt to have a clear view on code on screen
• and the last, but not the least important: although you have monitor details, that doesn't mean the next guy reading that code, will also have it ... he may be poor guy with the monitor from the fifties, with only 640x480 resolution ;-)

Answer 8

I find it amusing that many people justify (no pun intended) their 80-column preference by stating that "it's the limit for printing". Everybody knows that the ANSI/ISO print standard is 66 132-column lines per page.

That said, I don't think it really matters much today -- if the line is too long to see in your editor window, just change the font size. I typically set my font size to 9 points, but I have set it as low as 5 when I was trying to follow someone else's particularly convoluted switch logic.

As far as actually printing out code -- I gave that up when we stopped using continuous forms ("green bar" paper). Pity, as it was the really the ultimate for code reviews -- plenty of room for writing comments on the side, and you could unfold it as much as you needed for that rare routine that ran more than two pages long. Nowadays, you either have to risk getting the pages out of order, or (if you staple them) you have to keep flipping back and forth to follow the logic. The only other reason I printed out code was to review at home, and thanks to USB drives I don't have to do that any more.

Answer 9

80 is too limited, IMHO.

for (clients::iterator clientIt = clients.begin(); clientIt != clients.end(); ++clientIt)

There ya go. Busted. 120 should be a huge warning flag and pretty much absolute max. Honestly, if I can display it in 1600 * 1200 and it is not an unreadable line, I really don't mind. Common sense is better than arbitrary guidelines.

Answer 10

I still have a standard of 80 characters. There are several reasons for this.

1. Tradition. Most terminals were 80 columns wide, and thus most modern terminal emulators default to that width. If your code sticks to 80 characters, it can fit within a standard terminal window without wrapping, which is useful for greping through the code, looking at diffs, etc.
2. Even on a wide monitor, I like to have several windows open so I can compare code multiple windows, switch back and forth between two files easily (like header and code, or code and unit test), and so on. With 80 column windows, I can fit two editor buffers and a terminal all side by side (depending on the size of the monitor).
3. Code density is important to me. If I can fit a lot of code onto the screen at once, I can quickly glance around and understand a larger amount of code in a shorter period of time. Having to scroll up and down really slows down how quickly I can read code. Code with long lines tends to have a high amount of indentation and ragged lines, which means there is a lot of wasted space on my screen.
4. Deeply nested code (code that has a lot of indentation because you have nested classes, methods, loops, and so on) is generally a sign that the code should be refactored into shorter, simpler pieces.