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.
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 {}
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.
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.
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.
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.
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).
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.
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).
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.)
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.
Use tabs to align stuff on the left. This means putting some_key_1 on the next line. Also move the closing brace to a new line and add a comma after some_var_3.
Added advantage that you can move all of the lines around, :sort them or comment out individual ones without breaking anything.
Use spaces to align anything after the key, I usually align them with a tab stop so that several blocks line up.
Several benefits: easier to insert lines at the head or tail without making the SCM diff ugly, also avoids merge conflicts in those cases, and I use indentation of two levels to separate it from code.
Python is one-statement-per-line, which is already a pretty good limiter of line length. Just don't go crazy with ternary operators (which are hard to read anyway and thus against the Zen for more than the trivial cases) or literal definitions.
My FOSS libraries follow a 120-character wrapping limit and avoids alignment, but otherwise follows PEP-8. The main reason it was upped was the stupid arbitrary wrapping of lines that were only a few characters over the limit.
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.
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.
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.
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.
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.
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.
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.
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.
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.)
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.
Disk, 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.
> 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?
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?
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).
With 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.
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.
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.
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.
I 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.
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.
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.
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.
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.