10 ms·

80 chars per line is great

82 points by jaimebuelta 14y ago

Kaivo 14y ago
What about other languages? I find it harder in C/C++ when I have functions with too much parameters. It's almost less beautiful to look at. Do you change parameter names to shorter ones, add usings to avoid explicitly stating the scope, tab at 2 spaces instead of 3/4, increase the line cap to 90/100? 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?
- nmcfarl 14y ago
  Yeah - I was thinking about a Java codebase I was looking at a while back that had ultra verbose variable names like "BackupCopyOfLedgerUsedInWorstCaseScenarioProjections" You couldn’t even do a simple addition in 80 characters. This limitation seems fairly language specific, and has a lot of side effects for the rest of your style guide.
struppi 14y ago
When I can freely decide, I set the column indicator in eclipse to 100 and set eclipse to not enforce this limit (maximum line length=1000, never join lines). I prefer it like this because there are circumstances where longer lines make sense for me. Anyway, I try to keep lines as short as possible because I usually use a very large font for coding and have 2 files open next to each other...
cabirum 14y ago
80 chars ought to be enough for anybody, right?
ratsbane 14y ago
80 characters seems like such an arbitrary restriction. Once upon a time we were limited to 80 characters but we were also limited to monochrome ASCII text. Just as syntax highlighting improves readability, I think the occasional use of longer lines where appropriate improves readability - the shape of the code gives your eye additional clues about where you are in a section of code, allows you to have more lines on the screen at once, find what you're looking for faster, and isolates details that aren't crucial in getting the big picture. E.g. - inline lambdas or anonymous functions, strings, etc. 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.
- jimktrains2 14y ago
  > 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. And then someone working on your code on an eeePC will have a great time!
  - ratsbane 14y ago
    If you're doing a lot of development on an eeePC then line length may not be your biggest obstacle.
    - jimktrains2 14y ago
      Who are you to choose when and how I code. eeePCs work well in commuting situations.
      - tomsthumb 14y ago
        Visual Studio 2010 ain't quite zippy on a netbook. They are fantastic, but they do have notable limits.
        jimktrains2 14y ago
        Sure, but I dev in vim, linux, and the associated compiler/interpreter. A netbook is quite a handy for that type of dev.
  - cabirum 14y ago
    The options are: use smaller font size, enable word-wrap, buy a higher-resolution display (or two), use your IDE to auto-format code according to your preferences. I don't really see anybody using eeeePC for serious coding in 2013.
    - jimktrains2 14y ago
d23 14y ago
I had to fight with my team over the 80 character limit, but they eventually gave in. It works great in nearly every editing environment, and I've started trying to use it as much as possible in non-python projects as well. I can neatly fit two windows side-by-side in my IDE and read them both easily. I just can't go back to the old way of having the ends of lines hidden off-screen.
- Evbn 14y ago
  Do you code on a netbook? 2x120=140. At 7px each, which is generous (even if you are using some non-proportional font for archaic reasons or misplaced machismo) that is under 1000px wide.
  - leetrout 14y ago
    I agree with the parent- in my case I use a 27" display @ 2560x1440. I split the screen in half- browser or shell on one side and Sublime on the other. So Sublime gets 1280 pixels. With the project side panel open enough to see most of the project's directories it uses ~370px. The minimap (which I do leave open, and use, often) takes up ~50 pixels and the scroll bar for the edit window a final ~20 leaving me with 840 pixels that can show just at 100 columns. If I kill the minimap I get almost exactly 120 cols. For me, I have no qualms about 79 cols for the limit and enjoy being able to use my windows split to half the screen and still have some breathing room around the right edge of my code. I also find it awkward to scroll horizontally to see what's going on in a long line.
  - arnsholt 14y ago
    2 times 120 is 240. Which at 7px each clocks in at 1680. It'll work on a desktop monitor, but probably not on a laptop.
  - awj 14y ago
    I have a 27 inch monitor and still prefer an 80 character limit. It rarely forces me to mangle code and allows me to have four different files open side by side. It's especially useful for frontend development where I'm going to be editing html, css, and javascript almost all at once. This "hurr durr, we aren't on terminals anymore" argument is dumb. You aren't arguing with crotchety old geezers or people with stupid hardware choices. Quit assuming the people who disagree with you are idiots.
CapitalistCartr 14y ago
Long ago, I wrote Web pages to be served from OS390. Because it still enforced the 80 char limit from punch cards, I had to adhere to it, also. But no fancy editors for code directly in the machine. And when any line ran over 80, it would only render the first line of HTML. Took me hours to figure that one out. But I never ran across anything I couldn't make decent inside those 80 characters.
ajanuary 14y ago
Personally I find the splitting in the for loop much harder to read, though the smatch splitting is fine. 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.
- nonamegiven 14y ago
  I don't quite like the loop split, but that's because I've never like "continue the next line under the first argument of the series." It makes next lines start at inconsistent places and makes it harder to read. I usually bend that rule and follow the four space indent 90% of the time. But I do like the loop split better than the non-split, despite the above. I like the smatch split too. It looks like how you'd arrange bullets in a bullet list, one below the other, so you can see/scan them at a glance, without having to labor over where the next item is in a single line.
caioariede 14y ago
I love to work with a 79 chars per line limit. For those using vim, I use this snippet to automatically split my window at startup: https://coderwall.com/p/suj3fq https://coderwall.com/p/suj3fq
- q_revert 14y ago
  set colorcolumn=80 is another nice way to keep yourself within the bounds, it also has the bonus of not being a hard limit, just a visual indication that you're overstepping edit: (already mentioned)
bluedino 14y ago
With the long variable/class names used these days, and the availability of clear, small fonts and 16:9 displays, 80 columns seems silly. But I'm against raising it, even to 100 columns. 100 really isn't much more than 80. And then you start to lose things like being able two view two pages of code side by side. 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.
- vadman 14y ago
  I use a soft-ish guideline of 100 columns per line, but I mostly code in C# at work, so normally namespace/class/try-catch is already 3 indentations, and 80 chars is simply not enough for everything. I do my best to keep it between 80 and 100 chars. With a horizontal screen resolution of 1920 pixels, 2 pages of such code fit nicely side by side.
niggler 14y ago
In vim (appears the author is using macvim) you can use :set cc=81 to mark the 81st column and visually nag when you go over 80 chars
kstenerud 14y ago
80 characters is an accident of history, an accident that should be corrected. With an 80 character limit, you need to be mindful of the length of your identifiers. You start compromising recognizability in the name of fitting the line to an essentially arbitrary length (drop a few vowels, maybe use a less precise word). 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.
- GhotiFish 14y ago
  This isn't about the indentation. Look at the examples. you can see that allot of his code is indented heavily. This is about the amount of time and distance required to scan my eyes across a line to understand its meaning. How much do I have to read to understand a simple concept? This is also about the amount of screen real-estate i have to use. We arn't programming on VT100 terminal any more, damn right. NOW I get to have the compiler output and continuous integration output to my left. The directory, class structure and documentation to my right. I also get to split my screen to have two editors open for comparing snippets of code line by line. Merge conflicts and diffing are hugely common operations. merges have three parallel windows open at once! You, still, only have 80 characters to work with.
  - ajanuary 14y ago
    This isn't about the indentation. From TFA: Also, having the mandatory indentation whitespace increase the line width is a good visual way of minimising the nested loops in your code and suggesting, in a subtle way, to refactor anything that is indented more than about four times.
    - GhotiFish 14y ago
      yah, but I think the author is arguing side benefits. to be fair, so am I. The author was asserting 80 character line width was easier to read.
    - scarmig 14y ago
nonamegiven 14y ago
I think the three file views side by side image is one of the best arguments I've seen for 80 chars. But I'm predisposed to like that image, because I like 80 chars.
- masklinn 14y ago
  Or 2 files + a sidebar (using an IDE), 3-panes merge, etc...
- balloot 14y ago
  So why not make it 60 characters? Then you could have 4 files side by side! But seriously - I guess there is some workflow where you would like to have 3 files side by side, but I certainly have never felt like that is something I need. I would much rather have readable, verbose variable names, which I have found to be the first thing to get axed in an 80 char column setup.
  - snprbob86 14y ago
    Three files side by side is extremely common for those of us who have to regularly resolve merge conflicts. You put the common ancestor in the middle and the diverging changes on either side, then you edit both sets of changes in to that middle buffer.
    - balloot 14y ago
      I resolve merge conflicts as well. Every system I've ever used gives you one file with delineated chunks (<<<<, === >>>). Never once have I said "this is too difficult - I need three windows open." And even if I did say that sometimes, I can't imagine optimizing the character width of my code for that one use case.
      - nonamegiven 14y ago
        The most definite thing that should be taken from a thread like this is that it usually boils down to personal preference. In fact I'd say that personal preference in these matters should take at least as much preference as any available emperical studies. If you're in a group, and you don't get your way in the coding standards meeting, accept it and move on. You can do it! :)
ak217 14y ago
Screw arbitrary limits. 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.
- epochwolf 14y ago
  I do the same thing. I set a vertical guideline to 120 characters. Depending on the codebase I'll turn on wordwrap at 120 characters too.
  - heidar 14y ago
    I like a 80 column soft limit which I usually stick to and a 120 column hard limit which I use when I feel splitting the line and indenting would harm readability.
- zanny 14y ago
  This so much. Rather than "don't exceed 80 characters" the guidelines say "break up complex statements into multiple lines if it contains complex logic" and say that the target should be 80 - 120 chars per line. Just for comparison, I'm reading your comment at 140 characters width and I don't have much problem with that. I like my web text to occupy most of my screen. Only if I stretch it across multiple monitors to 160+ chars per line does reading become a chore. But it is a personal taste.
jspiros 14y ago
I find the 80 char limit nice as a suggestion/warning, a way of saying "are you sure your approach should require lines of code this long?" So, a good way to make sure that someone is writing readable code, which is otherwise the overall goal of PEP8. But, sometimes there are lines of code that are perfectly readable, maybe even more readable, despite exceeding 80 characters, and which become less readable by doing line continuations. (I would argue that line continuations make everything less readable, almost all of the time.) 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.
the1 14y ago
what? do programmers still layout their code using whitespaces manually? use code editors that support declarative stylesheet for layout and enable intuitive structural modification.
- tonyblundell 14y ago
  I prefer to be in absolute control of the layout. It's not that big a task.
mgrouchy 14y ago
80 character lines is perfect. Allows me a reasonable number of splits in vim and most importantly makes diffs/code that I get in my email readable. 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.
k_bx 14y ago
I'm ok that people don't use email/vim/sublimetext2 with splitting panes, but don't people use meld / kdiff3 for reviewing they're changes? And on my 1366x768 120-chars would be too wide to show in meld.
- k_bx 14y ago
  s/email/emacs/
- dbrgn 14y ago
  I much prefer colored unified diffs in my terminal (e.g. those from git) over side-by-side tools with multiple panes.
artificialidiot 14y ago
With default bells and whistles your IDE provides enabled, you'd be lucky to have a 79 char wide editing area. 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.
npsimons 14y ago
I love how a lot of responses here are of the condescending tone of "we aren't using vt100s anymore, grandpa", as if advocates for the 80 column limit are still running VIC20s in their mom's basement. I see this argument pop up a lot against things like vi and Emacs as well. 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.
- ak217 14y ago
  Yeah, but code readability has little to do with line width. I could show you perfectly unreadable code that fits in 80 characters because it's legitimately pre-indented by 40 and has to go to one word per line or shorten variable names to fit in 80, and wonderfully easy to read code that goes out to 160 (often because of some literal data that would otherwise just increase the vertical length). Also, it's funny to me that people talk about horizontal line length impacting readability, but never seem to talk about vertical length impacting readability as well. To me it's critical to keep related code clustered vertically as closely as possible without too much brevity: having to scroll/split view to see related pieces of code incurs a cognitive overhead. Arbitrary line breakage imposed by the 80-character limit gets in the way of that. (And don't get me started about teams that treat this as a limit instead of a guideline.) It's critical to give programmers the tools to make their code readable (good languages with good grammar and idioms), not arbitrary restrictions that try and fail to accomplish that indirectly.
  - ajross 14y ago
    > I could show you [...] wonderfully easy to read code that goes out to 160 I'm calling this bluff. No, you can't. If you actually have evidence I'd truly love to see it. Ridiculous line length is actually one of the most reliable code smells I know. Seeing something like that, I can virtually guarantee that it's an OOP-gone-wild mess of needless abstraction, tightly coupled data structures spread across a dozen files. It's going to be a spaghetti mess of nested if() constructs used where clean data-driven logic would have been better. It will be filled with commented-out-code. And it will probably have indentation that lies, lined up in incorrect columns waiting to fool the developer. Clearly you feel differently. Prove it. :)
cletus 14y ago
At Google, our Python style guide dictates 80 characters with 2 character indenting [1]. Java is the only exception at 100. 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.html#Line_length http://google-styleguide.googlecode.com/svn/trunk/pyguide.ht...
- rayiner 14y ago
  Lines of > 80 characters are really the last jabs at the dying corpses of typography and taste in the digital world. Typographically proper paragraphs are not wide across, because that forces the eye to move more while reading. This is a basic fact that has been known for literally longer than we've had printing presses. Wide lines are barbaric, and I'd go so far as to say that languages that can't be rendered comfortably in 80 character lines are nothing more the primitive tools of barbarians.
  - 5h 14y ago
    > Wide lines are barbaric I agree utterly, and enjoy the irony that I read your comment displayed as http://i.imgur.com/iJNs9SV.jpg http://i.imgur.com/iJNs9SV.jpg ... a full 258 characters ... HN could do with some responsive css to max-width comments above certain viewport widths!
vph 14y ago
The problem with 80 chars/line and Python, in particular, is list/dict comprehension. Naturally, as they replace a whole loop, comprehensions pack much information into one line. Consequently, there are many times when a list/dict-comprehension line that are clean and meaningful but had to be broken into 2 lines. And that isn't nice.
- tomsthumb 14y ago
  A foolish consistency is the hobgoblin of little minds.
- jaimebuelta 14y ago
  Having a list comprehension in 2 lines is really a problem? I find very readable something like result = [something(value) + value * 2 for value in values] I mean, I prefer one line, but if it has be in two (or more lines), I don't see the problem really
  - mst 14y ago
    Actually, with a minor tweak this gets even more readable - result = [something(value) + value*2 for value in values] I find indenting the subcaluse makes my eye flow naturally over the code. I'm normally doing this in perl, and often end up with functionalish code that looks like my @result = map { something($_) + $_*2 } grep { valid_candidate($_) } @all_candidates; but the same principle seems to apply nicely to both languages.
larkinrichards 14y ago
I really like the 80 character limit for readability, but I'm also a fan of what it does to git commits (and any other diffs). When I have to wrap code, say, function calls, I often use one line per keyword argument. When you have to change or add arguments later on, git recognizes that only one line -- the argument -- changed, instead of the entire function call changing.
Chris_Newton 14y ago
I agree completely with the author that readability is paramount and artificial limitations are often questionable. 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) and try to apply it to longer expressions like full_project_name.useful_package_name.handy_function(first_param, second_param, third_param) or something more complicated than a single function call? This leads to a debate where the most radical alternative proposed might be something like full_project_name.useful_package_name.handy_function( first_param, second_param, third_param) If you look at well typeset mathematics, which suffers a similar problem of scalability, there are often (at least) two different conventions for representing the same mathematical expression. For example, maths set using the TeX family probably has one version designed to read neatly in-line with other text, but another version designed to be clearer when set as a standalone display that might cross several lines. 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.
philwelch 14y ago
At 80 characters, I often find myself worrying about line length more often than worrying about the problem I'm trying to solve. 120 is fine. Also, I orient my (widescreen) monitor vertically so I don't have anything side by side anyway, just top and bottom where I can see more lines of code.
jlebrech 14y ago
what about having a limit for the number of lines, 200 lines?
- jotux 14y ago
  In mission-critical systems line limits are common. The first public example that comes to mind is the NASA JPL C Coding Standard(http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf). Check out Rule #25: >Functions should be no longer than 60 lines of text and define no more than 6 parameters. [Power of Ten Rule 4] >A function should not be longer than what can be printed on a single sheet of paper in a standard reference format with one line per statement and one line per declaration. Typically, this means no more than about 60 lines of code per function. Long lists of function parameters similarly compromise code clarity and should be avoided. >Each function should be a logical unit in the code that is understandable and verifiable as a unit. It is much harder to understand a logical unit that spans multiple screens on a computer display or multiple pages when printed. Excessively long functions are often a sign of poorly structured code.
NateDad 14y ago
100 characters seems a pretty reasonable compromise. Keeps lines from getting too long and hard to follow, but you're not splitting lines all the time just to keep under the limit, which also reduces readability. 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 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.
- jaimebuelta 14y ago
  Author here, just for reference, I use a iMac 27'' and Menlo 11 (I also have an extra screen, where I put other info, like mail) I anyway use the same setting when I use a laptop, though is not my main workplace.
VLM 14y ago
I think its a given that we'd all agree that writing portrait mode or landscape mode you still fundamentally take about the same number of square inches to do it. 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...
cabirum 14y ago
Ideally, IDEs should automatically take care of how to represent the code according to user's preferences. Also, IDEs can save files according to project's guidelines.
richardlblair 14y ago
The thing people miss here is the "Python related". If you need 120 characters on a line then you completely missed the "zen" of python. 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.
- obviouslygreen 14y ago
  This is painfully presumptuous. Generalizing others' code and constructs as "probably complete garbage" and suggesting that a 120-character line implies a "need to refactor" is either profoundly naive or grotesquely smug. I love Python, but programming languages don't have "zen," and reality is never so ideal that an 80-character line -- in and of itself -- can ever be assumed to imply anything useful.
  - Chris_Newton 14y ago
    Thank you for making that point. I used to work on some code that did a lot of subgraph matching. Subgraph matching in general is computationally expensive, so ideally you do it heuristically, searching for more likely elements of the subgraph you’re looking for first so you can skip over edges/vertices that have no potential as early as possible. Even then, if you’re looking for a complicated subgraph then you’re going to have a bunch of conditional logic that runs lots inside deeply nested loops one way or another. That kind of code is often unwieldy, simply because the algorithms it implements are unwieldy. However, arbitrarily factoring out some of the inner levels into separate functions, which might have little meaning in themselves and little potential for reuse out of context, just means when you’re trying to review/update the code you need to look in more than one place to find it. On top of that, you’re also incurring a bunch of relatively heavy function calls (many parameters might need to be passed in for context) right in the middle of deeply nested code or you’re trusting your optimiser to inline them reliably. So these days, whenever I see someone quoting dogma about how more than n levels of nesting are bad and your code needs refactoring if you hit their personal arbitrary limit, I cringe a little inside. Not all real world algorithms fit neatly into a dozen lines of code and a level or two of looping.
njharman 14y ago
> combined with the use of whitespace in Python, makes the code much more compact and readable 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
Glyptodon 14y ago
I hate the the 80 character limit. I never follow it, though using 2 char instead of 4 char indentation might help. 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.
cmars 14y ago
I mostly agree, but SQLalchemy queries and the occasional complex conditional could cause one to reconsider or start making allowances.
wyqueshocec 14y ago
I like to have my font size rather large. It reduces eye and neck strain for me and makes the long days more ergonomic. An "80 char/line" guideline is nice for that.
Grue3 14y ago
It's great for a language that is not whitespace-significant. Python requires hacks like backslash just to do a line break, which makes both alternatives (with/without line break) equally ugly.
tonyblundell 14y ago
Rules are there to be broken. 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 :-)
dbrgn 14y ago
I agree that we need a limit, but in my experience 80 characters is often too limiting and sometimes causes wraps that make the code less readable instead of more readable. 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).
ioquatix 14y ago
The only consistent method is to not wrap text at an arbitrary limit. Everyone can follow this and it is very clear. Readability may or may not be compromised. Dictating an arbitrary line width is exactly that: an arbitrary standard. If it works for you and your team, great, but ultimately it is a totally arbitrary choice. 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.

82 points by jaimebuelta 14y ago

Kaivo 14y ago

What about other languages? I find it harder in C/C++ when I have functions with too much parameters. It's almost less beautiful to look at. Do you change parameter names to shorter ones, add usings to avoid explicitly stating the scope, tab at 2 spaces instead of 3/4, increase the line cap to 90/100? 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?

nmcfarl 14y ago
Yeah - I was thinking about a Java codebase I was looking at a while back that had ultra verbose variable names like "BackupCopyOfLedgerUsedInWorstCaseScenarioProjections" You couldn’t even do a simple addition in 80 characters. This limitation seems fairly language specific, and has a lot of side effects for the rest of your style guide.

struppi 14y ago

When I can freely decide, I set the column indicator in eclipse to 100 and set eclipse to not enforce this limit (maximum line length=1000, never join lines). I prefer it like this because there are circumstances where longer lines make sense for me. Anyway, I try to keep lines as short as possible because I usually use a very large font for coding and have 2 files open next to each other...

cabirum 14y ago

80 chars ought to be enough for anybody, right?

ratsbane 14y ago

80 characters seems like such an arbitrary restriction. Once upon a time we were limited to 80 characters but we were also limited to monochrome ASCII text. Just as syntax highlighting improves readability, I think the occasional use of longer lines where appropriate improves readability - the shape of the code gives your eye additional clues about where you are in a section of code, allows you to have more lines on the screen at once, find what you're looking for faster, and isolates details that aren't crucial in getting the big picture. E.g. - inline lambdas or anonymous functions, strings, etc. 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.

jimktrains2 14y ago
> 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. And then someone working on your code on an eeePC will have a great time!
- ratsbane 14y ago
  If you're doing a lot of development on an eeePC then line length may not be your biggest obstacle.
  - jimktrains2 14y ago
    Who are you to choose when and how I code. eeePCs work well in commuting situations.
    - tomsthumb 14y ago
      Visual Studio 2010 ain't quite zippy on a netbook. They are fantastic, but they do have notable limits.
      - jimktrains2 14y ago
        Sure, but I dev in vim, linux, and the associated compiler/interpreter. A netbook is quite a handy for that type of dev.
- cabirum 14y ago
  The options are: use smaller font size, enable word-wrap, buy a higher-resolution display (or two), use your IDE to auto-format code according to your preferences. I don't really see anybody using eeeePC for serious coding in 2013.
  - jimktrains2 14y ago

d23 14y ago

I had to fight with my team over the 80 character limit, but they eventually gave in. It works great in nearly every editing environment, and I've started trying to use it as much as possible in non-python projects as well. I can neatly fit two windows side-by-side in my IDE and read them both easily. I just can't go back to the old way of having the ends of lines hidden off-screen.

Evbn 14y ago
Do you code on a netbook? 2x120=140. At 7px each, which is generous (even if you are using some non-proportional font for archaic reasons or misplaced machismo) that is under 1000px wide.
- leetrout 14y ago
  I agree with the parent- in my case I use a 27" display @ 2560x1440. I split the screen in half- browser or shell on one side and Sublime on the other. So Sublime gets 1280 pixels. With the project side panel open enough to see most of the project's directories it uses ~370px. The minimap (which I do leave open, and use, often) takes up ~50 pixels and the scroll bar for the edit window a final ~20 leaving me with 840 pixels that can show just at 100 columns. If I kill the minimap I get almost exactly 120 cols. For me, I have no qualms about 79 cols for the limit and enjoy being able to use my windows split to half the screen and still have some breathing room around the right edge of my code. I also find it awkward to scroll horizontally to see what's going on in a long line.
- arnsholt 14y ago
  2 times 120 is 240. Which at 7px each clocks in at 1680. It'll work on a desktop monitor, but probably not on a laptop.
- awj 14y ago
  I have a 27 inch monitor and still prefer an 80 character limit. It rarely forces me to mangle code and allows me to have four different files open side by side. It's especially useful for frontend development where I'm going to be editing html, css, and javascript almost all at once. This "hurr durr, we aren't on terminals anymore" argument is dumb. You aren't arguing with crotchety old geezers or people with stupid hardware choices. Quit assuming the people who disagree with you are idiots.

CapitalistCartr 14y ago

Long ago, I wrote Web pages to be served from OS390. Because it still enforced the 80 char limit from punch cards, I had to adhere to it, also. But no fancy editors for code directly in the machine. And when any line ran over 80, it would only render the first line of HTML. Took me hours to figure that one out. But I never ran across anything I couldn't make decent inside those 80 characters.

ajanuary 14y ago

Personally I find the splitting in the for loop much harder to read, though the smatch splitting is fine. 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.

nonamegiven 14y ago
I don't quite like the loop split, but that's because I've never like "continue the next line under the first argument of the series." It makes next lines start at inconsistent places and makes it harder to read. I usually bend that rule and follow the four space indent 90% of the time. But I do like the loop split better than the non-split, despite the above. I like the smatch split too. It looks like how you'd arrange bullets in a bullet list, one below the other, so you can see/scan them at a glance, without having to labor over where the next item is in a single line.

caioariede 14y ago

I love to work with a 79 chars per line limit. For those using vim, I use this snippet to automatically split my window at startup: https://coderwall.com/p/suj3fq https://coderwall.com/p/suj3fq

q_revert 14y ago
set colorcolumn=80 is another nice way to keep yourself within the bounds, it also has the bonus of not being a hard limit, just a visual indication that you're overstepping edit: (already mentioned)

bluedino 14y ago

With the long variable/class names used these days, and the availability of clear, small fonts and 16:9 displays, 80 columns seems silly. But I'm against raising it, even to 100 columns. 100 really isn't much more than 80. And then you start to lose things like being able two view two pages of code side by side. 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.

vadman 14y ago
I use a soft-ish guideline of 100 columns per line, but I mostly code in C# at work, so normally namespace/class/try-catch is already 3 indentations, and 80 chars is simply not enough for everything. I do my best to keep it between 80 and 100 chars. With a horizontal screen resolution of 1920 pixels, 2 pages of such code fit nicely side by side.

niggler 14y ago

In vim (appears the author is using macvim) you can use :set cc=81 to mark the 81st column and visually nag when you go over 80 chars

kstenerud 14y ago

80 characters is an accident of history, an accident that should be corrected. With an 80 character limit, you need to be mindful of the length of your identifiers. You start compromising recognizability in the name of fitting the line to an essentially arbitrary length (drop a few vowels, maybe use a less precise word). 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.

GhotiFish 14y ago
This isn't about the indentation. Look at the examples. you can see that allot of his code is indented heavily. This is about the amount of time and distance required to scan my eyes across a line to understand its meaning. How much do I have to read to understand a simple concept? This is also about the amount of screen real-estate i have to use. We arn't programming on VT100 terminal any more, damn right. NOW I get to have the compiler output and continuous integration output to my left. The directory, class structure and documentation to my right. I also get to split my screen to have two editors open for comparing snippets of code line by line. Merge conflicts and diffing are hugely common operations. merges have three parallel windows open at once! You, still, only have 80 characters to work with.
- ajanuary 14y ago
  This isn't about the indentation. From TFA: Also, having the mandatory indentation whitespace increase the line width is a good visual way of minimising the nested loops in your code and suggesting, in a subtle way, to refactor anything that is indented more than about four times.
  - GhotiFish 14y ago
    yah, but I think the author is arguing side benefits. to be fair, so am I. The author was asserting 80 character line width was easier to read.
  - scarmig 14y ago

nonamegiven 14y ago

I think the three file views side by side image is one of the best arguments I've seen for 80 chars. But I'm predisposed to like that image, because I like 80 chars.

masklinn 14y ago
Or 2 files + a sidebar (using an IDE), 3-panes merge, etc...
balloot 14y ago
So why not make it 60 characters? Then you could have 4 files side by side! But seriously - I guess there is some workflow where you would like to have 3 files side by side, but I certainly have never felt like that is something I need. I would much rather have readable, verbose variable names, which I have found to be the first thing to get axed in an 80 char column setup.
- snprbob86 14y ago
  Three files side by side is extremely common for those of us who have to regularly resolve merge conflicts. You put the common ancestor in the middle and the diverging changes on either side, then you edit both sets of changes in to that middle buffer.
  - balloot 14y ago
    I resolve merge conflicts as well. Every system I've ever used gives you one file with delineated chunks (<<<<, === >>>). Never once have I said "this is too difficult - I need three windows open." And even if I did say that sometimes, I can't imagine optimizing the character width of my code for that one use case.
    - nonamegiven 14y ago
      The most definite thing that should be taken from a thread like this is that it usually boils down to personal preference. In fact I'd say that personal preference in these matters should take at least as much preference as any available emperical studies. If you're in a group, and you don't get your way in the coding standards meeting, accept it and move on. You can do it! :)

ak217 14y ago

Screw arbitrary limits. 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.

epochwolf 14y ago
I do the same thing. I set a vertical guideline to 120 characters. Depending on the codebase I'll turn on wordwrap at 120 characters too.
- heidar 14y ago
  I like a 80 column soft limit which I usually stick to and a 120 column hard limit which I use when I feel splitting the line and indenting would harm readability.
zanny 14y ago
This so much. Rather than "don't exceed 80 characters" the guidelines say "break up complex statements into multiple lines if it contains complex logic" and say that the target should be 80 - 120 chars per line. Just for comparison, I'm reading your comment at 140 characters width and I don't have much problem with that. I like my web text to occupy most of my screen. Only if I stretch it across multiple monitors to 160+ chars per line does reading become a chore. But it is a personal taste.

jspiros 14y ago

I find the 80 char limit nice as a suggestion/warning, a way of saying "are you sure your approach should require lines of code this long?" So, a good way to make sure that someone is writing readable code, which is otherwise the overall goal of PEP8. But, sometimes there are lines of code that are perfectly readable, maybe even more readable, despite exceeding 80 characters, and which become less readable by doing line continuations. (I would argue that line continuations make everything less readable, almost all of the time.) 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.

the1 14y ago

what? do programmers still layout their code using whitespaces manually? use code editors that support declarative stylesheet for layout and enable intuitive structural modification.

tonyblundell 14y ago
I prefer to be in absolute control of the layout. It's not that big a task.

mgrouchy 14y ago

80 character lines is perfect. Allows me a reasonable number of splits in vim and most importantly makes diffs/code that I get in my email readable. 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.

k_bx 14y ago

I'm ok that people don't use email/vim/sublimetext2 with splitting panes, but don't people use meld / kdiff3 for reviewing they're changes? And on my 1366x768 120-chars would be too wide to show in meld.

k_bx 14y ago
s/email/emacs/
dbrgn 14y ago
I much prefer colored unified diffs in my terminal (e.g. those from git) over side-by-side tools with multiple panes.

artificialidiot 14y ago

With default bells and whistles your IDE provides enabled, you'd be lucky to have a 79 char wide editing area. 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.

npsimons 14y ago

I love how a lot of responses here are of the condescending tone of "we aren't using vt100s anymore, grandpa", as if advocates for the 80 column limit are still running VIC20s in their mom's basement. I see this argument pop up a lot against things like vi and Emacs as well. 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.

ak217 14y ago
Yeah, but code readability has little to do with line width. I could show you perfectly unreadable code that fits in 80 characters because it's legitimately pre-indented by 40 and has to go to one word per line or shorten variable names to fit in 80, and wonderfully easy to read code that goes out to 160 (often because of some literal data that would otherwise just increase the vertical length). Also, it's funny to me that people talk about horizontal line length impacting readability, but never seem to talk about vertical length impacting readability as well. To me it's critical to keep related code clustered vertically as closely as possible without too much brevity: having to scroll/split view to see related pieces of code incurs a cognitive overhead. Arbitrary line breakage imposed by the 80-character limit gets in the way of that. (And don't get me started about teams that treat this as a limit instead of a guideline.) It's critical to give programmers the tools to make their code readable (good languages with good grammar and idioms), not arbitrary restrictions that try and fail to accomplish that indirectly.
- ajross 14y ago
  > I could show you [...] wonderfully easy to read code that goes out to 160 I'm calling this bluff. No, you can't. If you actually have evidence I'd truly love to see it. Ridiculous line length is actually one of the most reliable code smells I know. Seeing something like that, I can virtually guarantee that it's an OOP-gone-wild mess of needless abstraction, tightly coupled data structures spread across a dozen files. It's going to be a spaghetti mess of nested if() constructs used where clean data-driven logic would have been better. It will be filled with commented-out-code. And it will probably have indentation that lies, lined up in incorrect columns waiting to fool the developer. Clearly you feel differently. Prove it. :)

cletus 14y ago

At Google, our Python style guide dictates 80 characters with 2 character indenting [1]. Java is the only exception at 100. 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.html#Line_length http://google-styleguide.googlecode.com/svn/trunk/pyguide.ht...

rayiner 14y ago
Lines of > 80 characters are really the last jabs at the dying corpses of typography and taste in the digital world. Typographically proper paragraphs are not wide across, because that forces the eye to move more while reading. This is a basic fact that has been known for literally longer than we've had printing presses. Wide lines are barbaric, and I'd go so far as to say that languages that can't be rendered comfortably in 80 character lines are nothing more the primitive tools of barbarians.
- 5h 14y ago
  > Wide lines are barbaric I agree utterly, and enjoy the irony that I read your comment displayed as http://i.imgur.com/iJNs9SV.jpg http://i.imgur.com/iJNs9SV.jpg ... a full 258 characters ... HN could do with some responsive css to max-width comments above certain viewport widths!

vph 14y ago

The problem with 80 chars/line and Python, in particular, is list/dict comprehension. Naturally, as they replace a whole loop, comprehensions pack much information into one line. Consequently, there are many times when a list/dict-comprehension line that are clean and meaningful but had to be broken into 2 lines. And that isn't nice.

tomsthumb 14y ago
A foolish consistency is the hobgoblin of little minds.
jaimebuelta 14y ago
Having a list comprehension in 2 lines is really a problem? I find very readable something like result = [something(value) + value * 2 for value in values] I mean, I prefer one line, but if it has be in two (or more lines), I don't see the problem really
- mst 14y ago
  Actually, with a minor tweak this gets even more readable - result = [something(value) + value*2 for value in values] I find indenting the subcaluse makes my eye flow naturally over the code. I'm normally doing this in perl, and often end up with functionalish code that looks like my @result = map { something($_) + $_*2 } grep { valid_candidate($_) } @all_candidates; but the same principle seems to apply nicely to both languages.

larkinrichards 14y ago

I really like the 80 character limit for readability, but I'm also a fan of what it does to git commits (and any other diffs). When I have to wrap code, say, function calls, I often use one line per keyword argument. When you have to change or add arguments later on, git recognizes that only one line -- the argument -- changed, instead of the entire function call changing.

Chris_Newton 14y ago

I agree completely with the author that readability is paramount and artificial limitations are often questionable. 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) and try to apply it to longer expressions like full_project_name.useful_package_name.handy_function(first_param, second_param, third_param) or something more complicated than a single function call? This leads to a debate where the most radical alternative proposed might be something like full_project_name.useful_package_name.handy_function( first_param, second_param, third_param) If you look at well typeset mathematics, which suffers a similar problem of scalability, there are often (at least) two different conventions for representing the same mathematical expression. For example, maths set using the TeX family probably has one version designed to read neatly in-line with other text, but another version designed to be clearer when set as a standalone display that might cross several lines. 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.

philwelch 14y ago

At 80 characters, I often find myself worrying about line length more often than worrying about the problem I'm trying to solve. 120 is fine. Also, I orient my (widescreen) monitor vertically so I don't have anything side by side anyway, just top and bottom where I can see more lines of code.

jlebrech 14y ago

what about having a limit for the number of lines, 200 lines?

jotux 14y ago
In mission-critical systems line limits are common. The first public example that comes to mind is the NASA JPL C Coding Standard(http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf). Check out Rule #25: >Functions should be no longer than 60 lines of text and define no more than 6 parameters. [Power of Ten Rule 4] >A function should not be longer than what can be printed on a single sheet of paper in a standard reference format with one line per statement and one line per declaration. Typically, this means no more than about 60 lines of code per function. Long lists of function parameters similarly compromise code clarity and should be avoided. >Each function should be a logical unit in the code that is understandable and verifiable as a unit. It is much harder to understand a logical unit that spans multiple screens on a computer display or multiple pages when printed. Excessively long functions are often a sign of poorly structured code.

NateDad 14y ago

100 characters seems a pretty reasonable compromise. Keeps lines from getting too long and hard to follow, but you're not splitting lines all the time just to keep under the limit, which also reduces readability. 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 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.

jaimebuelta 14y ago
Author here, just for reference, I use a iMac 27'' and Menlo 11 (I also have an extra screen, where I put other info, like mail) I anyway use the same setting when I use a laptop, though is not my main workplace.

VLM 14y ago

I think its a given that we'd all agree that writing portrait mode or landscape mode you still fundamentally take about the same number of square inches to do it. 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...

cabirum 14y ago

Ideally, IDEs should automatically take care of how to represent the code according to user's preferences. Also, IDEs can save files according to project's guidelines.

richardlblair 14y ago

The thing people miss here is the "Python related". If you need 120 characters on a line then you completely missed the "zen" of python. 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.

obviouslygreen 14y ago
This is painfully presumptuous. Generalizing others' code and constructs as "probably complete garbage" and suggesting that a 120-character line implies a "need to refactor" is either profoundly naive or grotesquely smug. I love Python, but programming languages don't have "zen," and reality is never so ideal that an 80-character line -- in and of itself -- can ever be assumed to imply anything useful.
- Chris_Newton 14y ago
  Thank you for making that point. I used to work on some code that did a lot of subgraph matching. Subgraph matching in general is computationally expensive, so ideally you do it heuristically, searching for more likely elements of the subgraph you’re looking for first so you can skip over edges/vertices that have no potential as early as possible. Even then, if you’re looking for a complicated subgraph then you’re going to have a bunch of conditional logic that runs lots inside deeply nested loops one way or another. That kind of code is often unwieldy, simply because the algorithms it implements are unwieldy. However, arbitrarily factoring out some of the inner levels into separate functions, which might have little meaning in themselves and little potential for reuse out of context, just means when you’re trying to review/update the code you need to look in more than one place to find it. On top of that, you’re also incurring a bunch of relatively heavy function calls (many parameters might need to be passed in for context) right in the middle of deeply nested code or you’re trusting your optimiser to inline them reliably. So these days, whenever I see someone quoting dogma about how more than n levels of nesting are bad and your code needs refactoring if you hit their personal arbitrary limit, I cringe a little inside. Not all real world algorithms fit neatly into a dozen lines of code and a level or two of looping.

njharman 14y ago

> combined with the use of whitespace in Python, makes the code much more compact and readable 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

Glyptodon 14y ago

I hate the the 80 character limit. I never follow it, though using 2 char instead of 4 char indentation might help. 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.

cmars 14y ago

I mostly agree, but SQLalchemy queries and the occasional complex conditional could cause one to reconsider or start making allowances.

wyqueshocec 14y ago

I like to have my font size rather large. It reduces eye and neck strain for me and makes the long days more ergonomic. An "80 char/line" guideline is nice for that.

Grue3 14y ago

It's great for a language that is not whitespace-significant. Python requires hacks like backslash just to do a line break, which makes both alternatives (with/without line break) equally ugly.

tonyblundell 14y ago

Rules are there to be broken. 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 :-)

dbrgn 14y ago

I agree that we need a limit, but in my experience 80 characters is often too limiting and sometimes causes wraps that make the code less readable instead of more readable. 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).

ioquatix 14y ago

The only consistent method is to not wrap text at an arbitrary limit. Everyone can follow this and it is very clear. Readability may or may not be compromised. Dictating an arbitrary line width is exactly that: an arbitrary standard. If it works for you and your team, great, but ultimately it is a totally arbitrary choice. 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.