5

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.

Annika Backstrom
  • 13,937
  • 6
  • 46
  • 52
agiliq
  • 7,518
  • 14
  • 54
  • 74
  • 25 **foot** monitors do not exist, and will not exist for a very long time. You mean _25"_. – SLaks Jul 07 '10 at 18:11
  • 2
    I suppose if you were using a projector... – Wayne Werner Jul 07 '10 at 18:13
  • 4
    Discussed here before: http://stackoverflow.com/questions/110928 – Alejandro Jul 07 '10 at 18:50
  • 4
    Slaks: I work for a really good company, they import monitors from future for all their devs. – agiliq Jul 07 '10 at 19:01
  • 4
    The short answer is that wrapping code to 80 columns is as absurd today as it's been for many years and will cause mangled, unreadable code; see PEP-8 itself for an example. Around 120 or 140 is a sensible wrapping width. – Glenn Maynard Jul 07 '10 at 19:16
  • (I'm not posting an answer because this was marked "community wiki", and I don't post answers to those--after having people who disagree with my answer repeatedly edit it to express *their* opinion months after the fact, making me babysit every answer indefinitely. Never use "community wiki"; that "feature" should be removed from the site.) – Glenn Maynard Jul 07 '10 at 19:18

8 Answers8

14

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.

Community
  • 1
  • 1
Wayne Werner
  • 49,299
  • 29
  • 200
  • 290
12

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
  • 53,300
  • 8
  • 96
  • 166
  • All of that addressed by good programming habits. Screen width is a matter of editor capability and taste. – dawid Jun 03 '20 at 23:25
11

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
  • 3,718
  • 3
  • 22
  • 24
7

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.)
ʇsәɹoɈ
  • 22,757
  • 7
  • 55
  • 61
  • 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 Jul 07 '10 at 19:15
  • 5
    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). – ʇsәɹoɈ Jul 07 '10 at 19:44
  • The compiler understands anyway. How it appears on your screen soon will be completely on the user preference side. IDEs are close to it, the last obstacle is git diff. – dawid Jun 03 '20 at 23:27
5

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
  • 14,562
  • 6
  • 50
  • 63
3

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
  • 528,062
  • 107
  • 651
  • 834
  • Agreed, also the compiler understands anyway. How it appears on your screen soon will be completely on personal settings side. IDEs are close to it, the last obstacle is git diff. – dawid Jun 03 '20 at 23:29
3

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
  • 25,806
  • 5
  • 67
  • 84
  • 2
    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 Jul 14 '10 at 13:16
1

In favor of short lines. Here are a few points I haven't seen mentioned much:

More specific error messages. If a single statement is split across two lines, and the error is on the second line, you immediately can rule out the first line as causing the problem.

Less chance of a conflict in version control systems like Perforce. (Incidentally this is also a good reason to alphabetize your include statements.)

People look at code on mobile devices. You can read 80 character lines from github comfortably on an iPhone. Longer lines require z shaped scrolling that gets annoying quickly.

funroll
  • 35,925
  • 7
  • 54
  • 59