5 ms·
Your code style guide is crap, but still better than nothing.
- gav 14y agoFun 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 14y agoWhy 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 14y agoWell, 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 14y agoI 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__ 14y agoAlso, 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.
- antihero 14y ago80 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 14y agoI 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 14y agoCode 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.
- caipre 14y agoI understand the readability argument for literature, where lines of text are left-justified. In code though, indentation is much more prevalent. Between indentation and alignment, some lines of code are unsettlingly clipped to a small fraction of the available 80 characters. I still recommend wrapping at 80 chars though.
- Shivetya 14y ago80 column punch cards are at times implied as the reason for 80 column displays. There are just some solutions that stick.
- npsimons 14y agoI 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 14y agoMaybe 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 14y agoNot 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 14y agoAutomation is a very nice thing. We, too, use Git hooks to run a wide array of checks and cleanup routines. The base that we use is from my hooks collection: https://github.com/amcgregor/snippits/blob/hooks/pre-commit-django https://github.com/amcgregor/snippits/blob/hooks/pre-commit-...
- peapicker 14y agoI 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 14y agoHe'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.
- Cacti 14y ago80 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.
- scott_w 14y agoHis 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 14y agoBut 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 14y agoI 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.
- amcgregor 14y agoDisk, flash, or RAM are concerns any time you have many copies of the files. One large file or millions of small ones, it adds up either way! I picked tab-based indentation because of the flexibility it gives me and anyone else reading the code. Savings elsewhere are icing on the cake. IDEs can automate bad behaviour as well as good, and yet spaces remain intra-word separators and tabs remain the character designed for indentation and alignment.
- pavel_lishin 14y 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 14y agoHow 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 14y agoI 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).
- amcgregor 14y agoWith no downsides to using tabs over spaces, and wanting to preserve readable SCM diffs, saving 20% of the space for such diffs just happens to be a nice side benefit, not the primary one. (The primary one being flexibility in presentation.) Saying you don't conform to a use case does not invalidate said use case.
- msutherl 14y agoThe 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.
- pavel_lishin 14y agoI'm a convert to spaces after someone pointed out that it's easier to make your code 'pretty'. // 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 }
- TallGuyShort 14y agoAnother tabs-only approach is to also add a single tab before some_key_1.
- DanBC 14y agoWatch out or you'll get // 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 }
- JensenDied 14y ago
- Ensorceled 14y agoI 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 14y 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 14y agoTrue 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 14y agoThe 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.
- guycook 14y agoI'm surprised at so many people taking a hard line at 80 characters. I guess you never wanted to automaticallyForwardAppearanceAndRotationMethodsToChildViewControllers
- swayvil 14y agoSo run all code through a formatter before perusing it. That way everybody gets what they want.
- keymone 14y agoi don't want to read the code. i want to scan the code. and 80rule makes it million times easier.