Your code style guide is crap, but still better than nothing.

Your code style guide is crap, but still better than nothing.(tech.matchfwd.com)

16 points by amcgregor 13 years ago | 48 comments

npsimons 13 years ago |

I closed the tab at the "Line Length" header; yet another person who Doesn't Get It, and proudly refuses to. There's a reason besides technical limitations (which in reality, didn't exist) that columns are best set to be no longer than 80 characters. Just as a hint, would you like to dump all your code into a single function in one file? No? Didn't think so.

Edit: I lied, I kept reading. Oh, why did I do that. Tabs instead of spaces because it looks better on his iOS devices? This article is bad, and the author should feel bad.

alanctgardner2 13 years ago | |

Maybe I`m biased because I write C on a daily basis, and only noodle around with Python occasionally:

- Having a standard line length is awesome. I can fit 3 80x4 terminals on my 1920x1080 screen, and I never have worry about anything overflowing or wrapping. You could pick a different length, if you`d like, but 80 is convenient.

- I`ve seen the `you can set tabs to whatever you want` argument before. It`s obviously at odds with the 80-column rule, because if you open it with the wrong config, wrapping everywhere. This happens disproportionately to new users - new hires and interns - and it`s a big pain to explain every time. Then they turn around and hit space 4 times anyways.

Your code style rules should definitely match your language. The author seems to be complaining that C-style rules don`t apply to Python. You`d think he would`ve realized when they started talking about wrapping if blocks in {}

beatgammit 13 years ago | | |

Not trying to start a flame war, but I am on the tabs side of the discussion. Most companies have rules about tabs/spaces (we use spaces, much to my chagrin), and it's pretty easy to set a rule.

I code in Go a lot now, and Go ships with gofmt, which formats your code for you (uses tabs by default). There are similar tools for every language I've used. This can be set in a pre-commit hook (or whatever the terminology is for non-git scms), so it's not really an issue. We do this, and it works like a champ.

amcgregor 13 years ago | | |

If your developers are pressing space four times instead of the tab (key), and the editors aren't capable of reasonable wrapping policies, you should probably replace either the editors they are using… or them. The key point of my article is that we have software to do all of this stuff for us. Hitting three more keys than necessary to indent is the fast road to carpel-tunnel and surely not the best use of developer time.

amcgregor 13 years ago | | |

Oh, forgot to mention: you can embed in source files editor instructions (between -*- for emacs, something I can't remember for vim) that specify a default presentation format.

amcgregor 13 years ago | |

Tabs not simply because it "looks better", but because it offers me the choice. Unfortunately, like most arguments on this subject, you have brought no logical counter-arguments to the table… just personal attacks (I never feel bad ;) and a false dichotomy of collapsing large codebases into a single file. That is, I'm sorry to say, not a very good argument.

npsimons 13 years ago | | |

I do regret the ad hom, and I don't have time right now for a proper rebuttal with links to far better programmers than I who have come down on the side of spaces and no lines longer than column 80, but I'll give you this: your basic premise (the one on the end of the title and the article) are true, and is a point I fully emphasize with. To be honest, I don't really care too much what formatting is used (and I can configure my editor of choice for anything you can think of, natch), but I insist that it be consistent.

Unfortunately, we don't all get to choose who we work with or that they use a decent editor, and either one or the other are usually lacking, therefore: no tabs, only spaces. Also, if you have a line of code longer than 80 characters, consider that that's an indication that it's too complex, and not so much that it's breaking some arbitrary line length rule. Does a function really need more than three arguments? Why not put them each on a line for better readability? Do you really need to put 15 operations on one line, when the compiler can inline them for you, and you can give more meaningful names to constant temporary variables?

As for putting all code in one function (or even one file), I thought it was fairly obvious: you can make things hard to read by using too long a line of code, just as you can make things hard to read by dumping them all in one unbroken file (line after line with no reuse and no compartmentalization of functionality).

mwill 13 years ago | |

My main display + editor, I use in two modes, 273 columns wide, or up to 410, both of which I feel comfortable with.

I'm guilty! I'll admit, When I know it's my-eyes-only, in languages with functional features, I tend to just brain-dump one liners if I 'see' them in my mind as one sequence of operations. It's easier for me to write, and much easier to read and parse later than multi line equivalent.

But I l also know that outside of private junk, this sort of thing is usually inappropriate, and downright harmful on teams with varying skillsets, where these lines can be impenetrable to some team members, and make the codebase far more intimidating than it needs to be. I segment and format anything above ~80 if anyone else is going to be involved.

So coming from someone who would violate almost any line length rule if no one was looking: I feel like a line length is appropriate in a style guide, or at the bare minimum a consensus on how much is too much.

martinced 13 years ago | |

Same here.

80 columns-wide have another huge advantage: 3-ways merge fitting on one screen.

Even with "only" 100 columns wide it's hard to do a three-ways merge side-by-side without wrapping on a 1920x1200 screen (I basically have to temporarily use a smaller font to be able to do my three-ways merge).

amcgregor 13 years ago | | |

I often use splits on my editors, and with 329 columns in my editor (with side-bar open) there is plenty of room. Fairly recently I was working with five simultaneous vertical splits and had no difficulty; my editor soft wrapped the few panes I wanted wrapped quite smoothly and without making the code any uglier or harder to read. While I do not agree with hard wrapping, in general, I still try to avoid run-on lines in my code, and in Python a newline is a statement separator so it's actually pretty hard to have run-on statements. (Literal definitions like lists and dictionaries can run-on, but I tend to hard wrap for SCM reasons.)

msutherl 13 years ago |

The tabs vs. spaces debate makes me very sad. I get it, big companies use spaces because interns are stupid and don't understand how tabs work. And some people monomaniacally want their code to look exactly the same everywhere.

But I wish it could just be acknowledged somewhere that, if you know what you're doing, tabs are better and have no downsides (except that you can't control how other people see your code).

Caveat: I really mean tabs + spaces for complicated formatting beyond the indent level of the current line.

Regarding 80 character width, I'm often coding on my laptop and I really appreciate it when code is kept within those bounds as it allows me to vertically tile 3 files without line-breaks. Also, I find that it forces me to write more succinctly. 'One idea per line' is a good idea and 80 characters is a good arbitrary limitation that helps me achieve that.

Ensorceled 13 years ago |

I find it ironic that the author says:

  Why, in the name of all that is holy, do our modern style
  guides still force us to manually wrap text to fit within
  80 columns? (That’s four and a half vertical splits of 80
  columns each on my monitor!)

but chooses a blog template that holds the width constant at 1000px. Perhaps there is a reason not to grow without bound horizontally?

I use 80 characters because it's just easier to read than 120 char lines. Plus, I rarely need to break lines anyway, even at 80 chars ... what the heck are you writing that needs to be 120 chars wide?

Also, I have 2 screens with 4 work areas (each half a screen):

* mvim (at 90 chars wide)

* two terminals

* browser

* developer tools

At 120 chars lines, mvim now needs to be 125/130 chars wide and require it's own dedicated monitor.

whatshisface 13 years ago | |

>what the heck are you writing that needs to be 120 chars wide?

Ever used java?

private static final Map<Class<? extends Persistent>, PersistentHelper> class2helper = new HashMap<Class<? extends Persistent>, PersistentHelper>();

if ((string1.toLowerCase().equals(Localization.getString('Yes')) || string1.toLowerCase().equals('yes')) && Cleaning.Verifier.isSafeInput(string2) && Cleaning.Verifier.isSafeInput(string3))

The first one I found on google, the second one is based on something one would normally expect to find in an average java codebase.

Ensorceled 13 years ago | | |

True with Java/ObjC you get very view verbs/nouns in the same "sentence" length.

But ObjC and Java developers also have the habit of writing long undebuggable sentences like:

response = object.veryLongMethodName(object2,object3).anotherLongMethodName().yetAnotherLongMethodName(object4)

amcgregor 13 years ago | |

The design of the blog is not under my control; if it was, it'd be a lot more flexible. (Responsive design FTW.)

The lines that are 81 characters long benefit greatly from the increase to 120 characters. That was the primary reason for increasing the limit beyond PEP-8's default 80 in my FOSS codebases. There were far too many lines whose wrapping was clearly stupid, and too much developer time spent worrying about it.

I have 4 screens (2@1024x768, 1@2560x1440, 1@1280x800) and frequently utilize multi-column splits. I only turn soft-wrapping on when I need it, which is almost never. If I were utilizing your setup I wouldn't enable it on your mvim display; <2% of the lines in any of the codebases I work on exceed 90 characters.

gav 13 years ago |

Fun fact: the VT-100 supported a 132-column display.

Anyway, there's a lot of advantages of trying to keep lines <= 78 columns wide. I don't make it a hard-and-fast rule, but usually overly long line is a sign that something's not right with the code and some refactoring is in order.

pc86 13 years ago | |

Why is a ~130-column line of code necessary a bad thing? I'm not saying it's good and that we should shoot for any specific number, but I don't see why shorter necessarily means better.

Disclaimer: I've been doing this for all of ~5 years so I have no experience with older terminal-style programming.

scarmig 13 years ago | | |

Well, I'd say it's highly language dependent, and a matter of sane preceding white space rules. Going by column count, ObjC or Java would be a million miles away from, say, C or Haskell.

I would argue that that's a mark against the former, but if you're using languages like them it's silly to try and fit everything into 80 characters. You still need a strict rule, btw: sooner or later some jackass will be putting in 200+ if you're not careful, which is insane in any language because it's utterly unreadable.

It has to do with how the eye physically moves: you want a given block of logic to be as square as possible, so moving from one portion of it to another, on average, minimizes the amount of distance your eye has to travel.

Deestan 13 years ago | | |

I generally disapprove of >80 width lines, but there are some cases in which they don't bother me, and that is boilerplate-ish code that you generally don't have to read all of to understand what it's for. For example macro-heavy C++ header definitions where each line ends in the same massive pile of definition.

The important bit for me seems to be that the stuff you have to read and understand should be in the <80 area.

mje__ 13 years ago | | |

Also, tools other than text editors - especially those designed to show code side-by-side like web-based code review tools (), etc become much harder to use when you have long lines.

scott_w 13 years ago |

His argument about size is undermined by the fact files are compressed before going across a network. Blocks of spaces can easily be condensed into a single character.

amcgregor 13 years ago | |

But not disk, flash, or RAM. And network transfers are not always compressed, say, if synchronizing with a WebDAV back-end with naive client software. (The vast majority of iOS WebDAV implementations suck badly in this regard.)

scott_w 13 years ago | | |

I don't think disk, flash or RAM are huge concerns for anything but huge files, to be honest.

Client-server communication software can improve over time, or be replaced by better software. Picking a style based on technical limitations that will be superseded anyway is surely what you're arguing against?

As a more general point, using spaces instead of tabs can still be handled easily by IDEs. It's possible to recognise that something is supposed to be an "indent", and then space it according to what your preferences are. Whether any current IDEs do that, I don't know.

pavel_lishin 13 years ago |

> tabs reduce storage, bandwidth, and I/O, three items that are important over weak links like 3G and on embedded devices with limited capacity and speed like my mobile phone.

Between minifying your css and js, and gzip compression, I doubt that tabs save you a significant amount of bandwidth when you're on your phone.

And how often are you working on code where using tabs instead of spaces seriously impacts your storage and I/O?

amcgregor 13 years ago | |

How often? Daily; I use my phone and iPad while I'm mobile, out having a smoke, or whatever. At home I use my iPad more than my laptop.

You don't keep your source code in a minified state, nor do you keep it gzipped; the storage/bandwidth/IO considerations are for SCM-tracked code where there are potentially many, many copies of the same file in different states.

If you could reduce a 34-line (1KB) diff by 20% (average of two indentation levels of four spaces each across those lines), why wouldn't you?

pavel_lishin 13 years ago | | |

I do not keep my code in a minified state, but we do minify it before serving it on the web.

I also do not access my code on a mobile device.

And I wouldn't reduce it because I have 122 gigabytes of space free on my machine, and absolutely do not care about saving 200 bytes worth of space, even considering it's per commit.

After all, you could reduce your code by even more by minifying it before adding it to your SCM, right? (I know, I know, if you take out line-breaks, diffs will become unreadable).

antihero 13 years ago |

80 character line length increases readability, and four spaces means that this is consistent everywhere.

If you have a tab character and someone sets things to like, two spaces, their line is going to be a dynamic length and it's going to shit up the code. PEP-8 looks fantastic, works, and leads to consistency across all Python code. Unless you are using a shitty IDE/editor, adhering to it is totally easy and completely painless.

webreac 13 years ago | |

I do not understand why there seem to be so much agreement on 80 characters line length. I often use 132 character. I have a rule that invite to avoid abbreviations in identifiers and I have often 4 spaces. If I limit to 80 character, all the line breaks decrease significantly readability.

nakkiel 13 years ago | | |

Code is just like literature. Too many words on a line and it looses the reader. All of this indeed depends on the density of the language you're using. If your're using extremelyLongVariableNames it may be ok to use 132 characters per lines but if you use shorter var_names, 80 characters is plenty of room to express yourself^W^Wwrite code.

Also, unix. Stop arguing about religion.

Shivetya 13 years ago | | |

80 column punch cards are at times implied as the reason for 80 column displays. There are just some solutions that stick.

Cacti 13 years ago |

80 columns exists for the same reason newspaper columns are about 2 inches and a novel is about 10-15 words wide---that is a width in which the human eye and brain can ready and fficiently absorb the information. Lines longer than 80 chars may be fine at times but they are generally a bad idea. Usually it's better to break the line up in some manner.

guycook 13 years ago |

I'm surprised at so many people taking a hard line at 80 characters. I guess you never wanted to

    automaticallyForwardAppearanceAndRotationMethodsToChildViewControllers

peapicker 13 years ago |

I prefer 132 col, 3-spaces for tabs.

But it doesn't really matter, these things can easily be handled by using gnu indent to put code the way you like it... and to also change it back to whatever style guide you must follow before checkin.

DanBC 13 years ago |

He's vaguely right that it's weird that wrapping problems are still with us, especially because it's something that programmers hit every day with both code length and email-quoting from mailing lists.

swayvil 13 years ago |

So run all code through a formatter before perusing it. That way everybody gets what they want.

keymone 13 years ago |

i don't want to read the code. i want to scan the code. and 80rule makes it million times easier.

Why, in the name of all that is holy, do our modern style guides still force us to manually wrap text to fit within 80 columns? (That’s four and a half vertical splits of 80 columns each on my monitor!)

// This doesn't look very nice thing = { some_key_1: some_var_1, [->][->][->]some_key_2: some_var_2, [->][->][->]some_key_3: some_var_3 } // Neither does this. thing = { some_key_1: some_var_1, [->][->]some_key_2: some_var_2, [->][->]some_key_3: some_var_3 } // Feels good, man. thing = { some_key_1: some_var_1, some_key_2: some_var_2, some_key_3: some_var_3 } // I want to beat you with an oar. thing = { some_key_1: some_var_1, [->][->] some_key_2: some_var_2, [->][->] some_key_3: some_var_3 }