tags:

views:

217

answers:

7

This seems like such a relic from the past in age of 25" monitors. I am looking for what stackoverflow members think about this, and do you always honor this recommendation.

+6  A: 

I try and use it, because I like to have some convention to keep me in place, but I know with dynamic line wrapping and suchlike, it is becoming less common. For example, the linux kernel for many years would take the convention as a solid rule, but recently, they have been accepting contributions with over 80 char long lines.

Another thing to keep in mind is that many editors offer split views. I often have two documents open in columns, and with a wide screen monitor, these columns (for me) come to about roughly 83 chars width. So the convention can still be useful, in some specific situations.

Blue Peppers
+9  A: 

Not everyone has 25" monitors. We use a dual 21" monitor setup here, but that is by no means the standard. Also there are many people who are not professional coders writing python with the latest and greatest setup, but poor college students (me!) with 19" or less (laptops, netbooks) monitors. Hobby programmers and "other" professionals who may not have as nice setups, and schools, public and otherwise are also limited in their desktop real-estate. But 80 character terminals more or less exist everywhere.

Limited width (really, any good standard) is A Good Thing™ because it gives a nice standard look across the board. I know that if I look at modules included in Python, or Pygame, or PyPy, or MyPaint, each one of those will have a pretty standard feel. This helps me with the time I need to comprehend the code.

For another look at code width, read what these people have to say.

Wayne Werner
+3  A: 

I think the 80 character limit is great, and works beautifully in Python (maybe not so much in Java or JavaScript, but is very doable in Python). I always try to honor it. I work on 2 24" monitors, 1 portrait, the other landscape, and its invaluable to allow me to have 2 windows side by side on the portrait display, or ~3.5 on the landscape.

While editors will wrap long lines, it wraps them in an ugly way which disrupts the flow of code, making it harder to read.

Richard Levasseur
+4  A: 

79 or 80 character line limits are perfectly sensible today. Several others have pointed out that not everyone has a monitor as wide as yours. Moreover, your GUI editor is not the only place where code is read or written. Here are a few more places where long lines are a real pain:

  • Side-by-side diffs.
  • Code snippets in email.
  • Text-mode consoles. (For example, during production server debugging.)
  • Printouts.
  • GUI editors used by people who don't maximize every application to fill the desktop. (I personally like to keep API docs on one side of my screen and my editor on the other side.)
Forest
This is painfully contrived. Printers aren't limited to anything close to 80-columns and you can easily edit longer lines in a console during short-term debugging.
Glenn Maynard
Not contrived at all. All the examples I gave (including the two you disagree with) come from actual, multiple, real-world experiences. There are many kinds of printers in use, and many kinds of software driving them. Many operations personnel don't really want to have to edit your code in vi just so they can tell where the line breaks should be. I could go on, but I think I've made my point. One thing learned from such experiences is to remember the whole world doesn't do things the way I do (or the way you do).
Forest
+6  A: 

I always follow the 80-character limit, in any language, for a few reasons:

  • Consistency, consistency, consistency.
  • Possibility of multiple views in multiple windows or columns.
  • Seamless switching between old and new editors.
  • Encourages keeping nesting shallow, arguments few, and expressions succinct.

The last is the most important, and integrates comfortably with verbose naming conventions. If it doesn't fit on one line or neatly break into two, then regardless of your naming, the code probably needs to be adjusted anyway.

Though I refer to it as the 80-character limit, in practice it's a good idea to keep to 79 or even 78 columns, for those console editors that insist on a scrollbar and a border.

On a related note, I use tabs for indentation and spaces for alignment. This way, formatting is not disturbed if the tab size is changed. With regard to the 80-column rule, though, I minimally ensure that the code does not hit the margin when using 4-column tabs, since tab sizes higher than that are less common.

Jon Purdy
+2  A: 

Trying to keep code within a reasonable line length for readability is a good idea.

Rigidly limiting code to a specific number of characters, adding extra line wraps (that impair readability) just to comply with such an arbitrary stricture is not sensible.

(It could be worse. You could be in a Java project with those insaneLongJavaNames combined with 80 column limits and 8-column tabs. Unreadable over-wrapped madness.)

bobince
+1  A: 

Short lines are easier to read - this is why most books have line lengths in the 60-80 character range, and newspapers break their text up into multiple columns to keep the line length down. If the lines are too long then I think the eyes become strained from moving that distance left-to-right, and has more trouble staying on the same line.

Dave Kirby
That short line-length for books (and especially newspapers) is because you're reading prose, not code. I rarely read code left-to-right, top-to-bottom, and I suspect few others do either. Shorter lines do make code more readable, sometimes, but it's mostly not for the same reason it helps in books.
Peter Hansen