

Your code style guide is crap, but still better than nothing. - amcgregor
http://tech.matchfwd.com/your-code-style-guide-is-crap-but-still-better-than-nothing/

======
npsimons
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
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
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
Automation 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-...](https://github.com/amcgregor/snippits/blob/hooks/pre-commit-
django)

------
msutherl
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.

~~~
pavel_lishin
I'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 }

~~~
JensenDied
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.

    
    
      thing = {
      [->]some_key_1: some_var_1,
      [->]some_key_2: some_var_2,
      [->]some_key_3: some_var_3,
      }

------
Ensorceled
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
>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
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)

------
gav
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
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
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.

------
scott_w
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
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
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.

~~~
amcgregor
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.

------
pavel_lishin
> _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
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
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).

~~~
amcgregor
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.

------
antihero
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
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
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.

~~~
caipre
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.

I still recommend wrapping at 80 chars though.

------
Cacti
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
I'm surprised at so many people taking a hard line at 80 characters. I guess
you never wanted to

    
    
        automaticallyForwardAppearanceAndRotationMethodsToChildViewControllers

------
peapicker
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
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
So run all code through a formatter before perusing it. That way everybody
gets what they want.

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

