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.
- 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 {}
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.
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).
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).
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.
// 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 }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.
thing = {
[->]some_key_1: some_var_1,
[->]some_key_2: some_var_2,
[->]some_key_3: some_var_3,
} thing = {
[→][→]some_key_1: some_var_1,
[→][→]some_key_2: some_var_2,
[→][→]some_key_3: some_var_3,
[→]}
Why suffer a problem when it's easily avoided? :)
// 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 }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.
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.
Disclaimer: I've been doing this for all of ~5 years so I have no experience with older terminal-style programming.
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.
The important bit for me seems to be that the stuff you have to read and understand should be in the <80 area.
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!)
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.
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.
But ObjC and Java developers also have the habit of writing long undebuggable sentences like:
response = object.veryLongMethodName(object2,object3).anotherLongMethodName().yetAnotherLongMethodName(object4)
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.
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.
Also, unix. Stop arguing about religion.
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.
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?
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 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).
automaticallyForwardAppearanceAndRotationMethodsToChildViewControllersBut 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.