80 chars per line is great

Even 100 can be awkward to fit into. Lord knows I've renamed variables to avoid splitting a line on several occasions.

But what a lot of posters here seem to miss is that it isn't about the width of screens for editing, it's about the width of screens for reviewing so you need twice the real estate.

Add in doing interactive merges and you need three times the width.

This really comes down to the principle of enforcing a common style (for an organization or project). A lot of people rail against "arbitrary limits" and "arbitrary style guidelines" as it's something extra they need to learn and adds no value (according to them). I've seen people here for 6+ months again still fighting this.

Such things (IMHO) have value as it adds a reasonable level of consistency across teams, it avoids commits on files due to stylistic changes (which may or may not be automatic from IDEs, etc) and, most importantly, defuses a lot of the aesthetic-driven boneheadedness that we engineers are prone to.

The last point is really important. Otherwise you'd have engineers and groups fighting over where to put curly braces, 2 space indents vs 4, whether tabs are OK, etc--none of which actually matters.

So if you feel your creativity somehow stifled over 80 characters, I'd strongly suggest you just abosrb it, get over it and move on to things that actually matter.

[1]: http://google-styleguide.googlecode.com/svn/trunk/pyguide.ht...

Yes, we realize that monitors are bigger, resolutions are higher, etc ad naseum. None of that matters. What matters is code readability. So what if you can fit 120 characters in your code editing window? I can fit more than 400 across two monitors, should the new line length limit be 400? Why stop there, why not just let lines be endless and have the editor wrap them? Answer these questions, and you've answered why people still like the 80 column guideline, or even care about code formatting at all. Code is only incidentally written for machines to execute; it should be written for people to read.

Using a width limit to coerce into indenting less is just plain silly. If you don't want high levels of indentation, put THAT in your coding guidelines. Don't rely on side effects.

Personally, I prefer the 120 characters per line guideline. Most code I see starts looking very ridiculous when trying to accommodate the 80 characters max width, and it starts becoming hard to follow lines when exceeding 120 characters. So, to me a soft 120 characters guideline is the nice medium between the fact that it's no longer 1980 and the need to make lines easy to read.

Also, in most cases readability has almost nothing to do with line width (in fact it can suffer greatly from too much line breakage), and everything to do with how the programmer chooses to structure their code, aided by language idioms.

The other problem is that 100+ column lines are just flat out hard to read. It's hard to follow text that far across these screen. A few years ago when I was working with Objective-C I came across methods used with each variable on one line and really grew to like that.

It's similar to the way source code is laid out in books. But is that because the code is more readable that way, or is it a consequence of the layout? Books are taller than they are wide and usually have generous margins.

Having to go beyond about 85 characters is a good indication that you probably need some refactoring in your python code. As the idiome states, "Flat is better than nested."

Your if, in an if, in an if, in a for, in a method, in a class is probably complete garbage. Even in other languages, if you are so nested that you legitimately need 120 characters then you likely need to refactor. Your code that is nested to oblivion will prevent anyone from being able to give you a thorough code review which opens you up to unnecessary risk.

But I never ran across anything I couldn't make decent inside those 80 characters.

The other rule that I personally ignore, and when I'm managing a project I have my developers ignore, is the suggestion to use spaces instead of tab characters for indentation. Of course, with Python, you must use one or the other, but I prefer tabs.

In both cases, it comes down to my belief that individual coders should have the ability to customize their experience without forcing it on everyone else. When you use spaces instead of tabs, and indeed, when you use line continuations, you're forcing your (the author's) exact view of the source code on everyone you're working with. If you use tabs, and don't use line continuations, others with specific needs (2 character tabs, 4 character tabs, 8 character tabs, 60 character-width editors, 100 character-width editors, etc.) can, with any modern editor, customize their view (using variable-width tab stops, and soft line wrapping) to what they're comfortable with.

One observation is a fixation on horizontal space never on vertical. If you can't make sense of the big picture without scrolling vertically then you're probably doing it just as wrong as requiring horizontal scrolling to see the little picture.

Two interesting analogies:

RISC vs CISC. Doing something RISC like with simple little operations but the order and block control are super important? Go "RISC" landscape mode. Doing something ridiculous complicated at the operation level? Go "CISC" portrait mode and only do one "weird thing" per line.

Another interesting analogy is I've been in this game since 1981 and the physical display ratio has consistently gotten shorter and fatter every year (kind of like my body, sorta). Like it or not, the style trend is that someday our display hardware is only physically going to be capable of something weird like 800 characters across and only 8 lines up and down. You might have a 10 inch tall display but if 6 vertical inches are taken up by window bars and tab bars and ribbons and 25 toolbars and a bottom status bar, well you're only getting 4 vertical inches. Doesn't matter much if you like it or not, you'd best get used to it as styles don't seem to be changing, not even the 1st or 2nd derivative of the ratio over time...

On a semi-related subject, what about the vertical limit of the code? I often heard that a function should fit in one page, but that also depends on the screen resolution. Also, the 80 chars rule would increase the amount of line instead. How do people deal with that in general?

For those using vim, I use this snippet to automatically split my window at startup:

https://coderwall.com/p/suj3fq

    :set cc=81

If you're having trouble fitting two 100 character wide files side by side, there's two things you need to do:

#1 - get a screen with a decent resolution. 1920px wide should be standard for any developer worth his salt. Yes, this means "don't develop on a 13 inch laptop screen"... you're a developer, this is the main tool to do your job, make it a decent one.

#2 - use a real font. Courier New (or whatever the corollary is on Linux/OSX) is not a real font. I prefer proggy fonts (http://www.proggyfonts.com/index.php?menu=download)... they are incredibly more compact and still very readable... you get significantly more characters on the same line.

When I work on a codebase with formatting standards I try to follow them. This is 2013, though, and when I work on my own stuff I format it to get the most readability on my Macbook or 32" 1080p desktop screen, not a VT100 from 1987.

Because of Python's significant indentation is exactly why I can't stand 80 char limit. Breaking lines, causing "false" visual structure destroy's Python's readability.

Seeing more logic vertically is far more important than horizontal.

I've been on teams that choose horrible names, used strange constructs, etc. just cause they fit on 80 char. Also wasting huge amount of time getting shit under 80char. Oh, and 80 char leads to people using import from over import (to avoid fully qualified names), which introduces bugs (name conflicts) and tons of confusion / lookup time wasted figuring out "process" is from some.lib and is not local,, or the one from some.other.lib

I would favor splitting only if you're indenting to line up with the first couple of tokens. In those cases the pattern is obvious as soon as I start reading, and my brain switches to scanning vertically. I find it jarring to have to switch from having read most of a line to suddenly scan vertically.

It seems like the example doesn't demonstrate the point that precedes it at all. Apparently in this example an 80 character limit doesn't promote re-factoring, it promotes splitting lines. Which makes the justification for 80 characters being a typical line length + 4 indentations a bit weak and 80 is back to being arbitrary.

I stick to 80 chars 99% of the time because long lines are more difficult to read.

But if a line ended up being 84 characters wide I wouldn't go replacing variable names or hacking a single function call onto multiple lines to fix it.

No one has died yet :-)

The main reason I hate it is pretty simple: I think it encourages using cryptically named variables. I find that using properly descriptive naming often leaves lines around 90 to 100 chars, particularly with 4-space indents and several arguments or a chained call. I also don't find the suggested practice of implied multi-line via unclosed parens leads to good readability in many cases.

That said, I agree there should be some limit. My usual practice is to set it at 120 chars, though I find it rare for a line to exceed 90 to 100 chars.

Also, I believe that text editors are generally catching up in this regard and doing a good job of intelligently indenting code that wraps over multiple lines. This means you can choose an editor width that suits your needs rather than having it dictated by someone's arbitrary choice.

I use a vim colorcolumn at 80 characters as a soft limit, but the hard limit for my projects is at 100 (or 99, to be exact). This has proven to be a nice guideline to write readable code, versus the 80 hardlimit that forces you to write short code (which sometimes is less readable than a clean & clear line with 90 characters).

And that isn't nice.

That being said, as with all things(especially guidelines), apply common sense liberally. Which in Python is one of the guidelines of pep8 on writing readable code.

An "80 char/line" guideline is nice for that.

There are modern options though:

1. Disable unnecessary stuff on your IDE. 2. Don't use a IDE, use a dedicated editor. 3. Don't use an editor from a VGA console. 4. Stop pretending you code on a vt100.

I see no wrong with a sensibly long line which is longer than 79, just as I see no wrong in keeping multiple parts of code visible at all times. There shouldn't be hard limits or carved to stone guidelines.

Having said that, whenever this topic comes up, we always seem to fall into the same trap of comparing one dubious representation (very long lines) with another (awkward breaks to avoid crossing an imaginary limit). Beyond a token comment on not nesting too deeply, and a token reply that sometimes deep nesting really is tidier than artificially separating the inner levels somehow, we rarely consider whether what we’re representing is fit for purpose. Does it really make sense to take the basic syntax we use for short expressions like

    short_name(easy_param, other_param)

    full_project_name.useful_package_name.handy_function(first_param,
                                                         second_param,
                                                         third_param)

    full_project_name.useful_package_name.handy_function(
        first_param, second_param, third_param)

There are many tools for tidying up those displays, aligning things in logical ways. There are also conventions for breaking expressions too wide to fit on a single line, and sometimes those conventions do opposite things when setting an expression in-line to in displayed form, for example when deciding whether to leave a trailing + at the end of one line or move it to the start of the next. There is also a general idea that if you’re dealing with a lot of expressions that don’t fit, you should be looking to define self-contained parts of those expressions separately, and incorporate them indirectly using a more concise notation within the larger expressions. There are even subtle cross-references like numbering the key equations (only) and then adding a note like “by (1) and (2)” in the margin to help the reader navigate a complicated series of results. All of these ideas fit within the broader typography of setting a paper or thesis, where you still want good general readability in terms of (physical) line lengths, numbers of columns, use of tables, positioning of displayed content, and so on.

In programming, we have some of the same basic ideas, particularly separating out smaller parts of a larger whole as separate functions or variables for exposition, but we haven’t really developed the same depth of typographical conventions. Almost everything is based on the idea of taking that basic syntax that works on a single line for relatively short expressions and trying to make it work for arbitrarily large expressions across many lines with nothing but a line break and fixed tab/space characters as tools.

I think this is partly because our text-based editors typically don’t separate the meaning of our code from its layout. Even ideas like elastic tab stops, which might be everyday alignment tools in programming languages that use meaningful indentation, are still esoteric. A few functional languages promote ideas like “let x in y” or “x where y” syntax to help separate out subexpressions, but on the scale of functions separation implies creating a new self-contained function to do part of the work, which comes with its own scope, which means explicitly passing values in and out when they were already conveniently available in the all-in-one function.

I don’t see the controversy over X characters per line limits going anywhere until we get over these more fundamental problems of conflating code layout/presentation with code meaning. We need to be able to express the ideas in our programs systematically and have our editors and diff tools and code review software present those ideas in a suitable layout that adapts to both the idea itself and its context. Sadly, that’s not going to happen as long as we keep asking questions like how wide a tab stop should be, and not asking questions like whether we should even have tab stops at all.