Why "2 Spaces"?

[nikolowry]

Preface: Not trying to cause a flame war.

---

I love the idea of an 'opinionated standard' and wholly agree with most every rule - except the preference of 2 spaces.

Preferring 2 spaces is an accessibility issue. It's too difficult for me (and I imagine others) to read code with such little white space.

There isn't any wiggle room in at-least making the space length optional, with the only options being 2 or 4? I'm already assuming the answer will be no, so I'll most likely just go the route mentioned in the README:

If you really want to configure hundreds of ESLint rules individually, you can always use eslint directly with eslint-config-standard to layer your changes on top.

I really dislike filing issues like this, but was unsuccessful finding a previous issue that addressed it and was also unable to find an explanation for it on http://standardjs.com.

Good effort nonetheless, even if I can't enjoy it because of my poor eyesight.

[feross]

@nikolowry Sorry that 2 spaces doesn't work for you. I occasionally wish that the JS community had settled on 4 spaces, since that would discourage deep nesting. The Linux kernel takes this to the extreme and does 8 spaces!

Unfortunately, we can't change this at this point in time: it would be far too disruptive.

[nikolowry]

@feross do you have any links/literature on when and where the "JS Community settled on 2"? The only time I can ever recall "2 spaces" being popular was during the pre-compiling/pre-minifying JS years and the rational was using 2 spaces helped save KB.

Not trying to pester, genuinely curious when this became "standard"

[feross]

I'm not sure when this became the dominant style, but all the popular style guides, like Standard, and the Airbnb, Google, and Idiomatic guides mandate 2 spaces. Also, Node.js and npm themselves use 2 spaces. npm actually uses standard :)

[nikolowry]

@feross I started noticing some of the bigger repos were using standard - just didn't know what came first "the chicken or the egg". If I had to put money on it - I'd be willing to wager that Google's Python style guide was used as the basis for the JS rules, which then snowballed into "standard practice".

Anyways, cheers! However I'm still baffled how anyone can read 2 spaces.

[feross]

@nikolowry Good theory!

[MartinMuzatko]

I'm also bothered a lot by the 2 spaces rule. It became standard almost everywhere unfortunately.

IDE Defaults
It is maybe important to note, that some major IDEs still use 4 spaces as the defualt.

VS Code has 4 spaces set as default.

Sublime Text also defaults to 4: http://www.sublimetext.com/docs/indentation

Atom has decided to switch to 2 as default.

Readability

I can very much agree with @nikolowry that 2 spaces is really unreadable. I get bothered by that easily. But thanks to tools like editorconfig, I can easily change to make it readable for me and on git commit, I can format it back. It does not work that seamlessly, but its a start. I would love to see more solutions on how to deal with this. Unfortunately, this is something we need to rely on our IDEs to get this right.

When working in the terminal, you do not want to spend extra time when searching for pieces of codes, but there, indentation does not concern me as much when working with the code. However, especially with git diff and git add -p, you depend on the decisions made by others.

Indentation Punishment

Indenting should hurt. Whenever you need to indent something further than 5 or 6 times, you quickly see that there is something wrong with how the code is structured.

We do it like that, because everyone does that

While looking at how others organize themselves can be a good source for inspiration, I doubt that it is the best way to find a good standard. While whitespace can be a quite personal topic with everyone having their own recommendations, I don't see what the main appeal of 2 whitespaces is. This also aligns nicely with the ancient but still valid rule of ~80-90 characters per line.

Opposed to other styleguides, standardjs removed semicolons completely, which is a bold move. I would love to see us trying to find a standardization process for this issue, other than pointing fingers and saying "they do it, so we do it".

Other than that, I am more than happy for any literature or historical proof why 2 whitespaces is a good choice.

[nikolowry]

@MartinMuzatko after venting about this a year ago, my ultimate solution was doing the following:

• Add the necessary dependencies, as documented in the eslint-config-standard repo:

npm install eslint eslint-config-standard eslint-plugin-import eslint-plugin-node eslint-plugin-promise eslint-plugin-standard

• Then add an ESLint config to the root of your project, i.e .eslintrc.js

module.exports = {
    extends: ['standard'],
    rules: {
        'indent': ['error', 4]
    }
}

Attempted to find an alternative styleguide prior to settling on customizing StandardJS -- but couldn't find any that I felt were truly "zero-config", so I've been using this approach instead. While it requires an extra step, it was a good choice for my workflow.

[LinusU]

@nikolowry while I would personally recommend using 2 spaces just because that is what the majority of the JavaScript community are using, here is an easier way for you to configure 4 spaces:

1. Install standardx

   npm install standardx

2. Add the rule to your package.json

     // ...
     "standardx": {
       "rules": {
         "indent": ["error", 4]
       }
     }
     // ...

3. Use standardx instead of standard

      "scripts": {
   -    "test": "standard && mocha"
   +    "test": "standardx && mocha"
      }

[nikolowry]

Thanks for the tip @LinusU!