eslint-config-sevencooks

SevenCooks coding rules as eslint config.

Provided configs

sevencooks

Base rules for every project.

These rules assume a modern project with full ES2015 support and a module system with a node.js-like resolving behavior (like node.js and webpack).

The base rules do not define an env, so you might do that for yourself in order to enable specific globals.

Add an .eslintrc.json to the project's root folder:

{
    "extends": [
        // Base rules for every project
        "sevencooks"
    ],
    "env": {
        // Enable node globals
        "node": true
    },
    // Do not search for further eslint configs in upper directories
    "root": true
}

In case you changed the resolving behavior, you can use the resolvers option of the eslint-plugin-import. For instance, if you're using webpack, you just need to install the eslint-import-resolver-webpack module and tell the plugin the location of your webpack.config.js like this:

    "settings": {
        "import/resolver": {
            "webpack": {
                "config": "config/webpack.config.js"
            }
        }
    },

You don't need to do that if you stick to node's/webpack's default resolver.

sevencooks/react

Additional rules for React development. Can also be used in other JSX environments, like Preact:

{
    "extends": [
        "sevencooks",
        "sevencooks/react"
    ],
    "root": true
}

Goals

Coding rules and coding conventions are always a hot topic because they are very subjective. However, for the benefit of all team members, it's reasonable to have common rules among projects.

In order to make good decisions, we judge our rules by these features, ordered by priority:

1. Ease of reading
2. Ease of refactoring
3. Ease of writing

Because,
code is read more often than it's changed and
code is changed more often than it's written.

Since the "ease of reading" tends to be very subjective again, we should stick to well-known typography rules:

Avoid long lines

This line is very hard to follow because it is very long. The human eye is not used to follow a straight line for so long that's why it feels more comfortable to have some line breaks in between

Avoid unbalanced lines

The following two lines look a little bit strange because the first one has a lot of text and is very long while the second
is short.

Use horizontal whitespace

this=is+hard-to;read-because/we,can't,distinguish&tokens
andLongVariableNamesAreHardToReadBecauseCamelCaseHasNoWhitespace

Don't use too much vertical whitespace

This is a line with some text in it, and after that


There is


another


blank


line and than

another blank link and again

Avoid unnecessary characters

(yes) = {we: (are)}, (programmersWhoAreUsedToReadThis - but);

this = is ? nicer : to(read);

Repeat familiar patterns and stay consistent

it =is distracting  {to :use } { whitespaces}= inconsistently .

We should also take into account that code is different than regular paragraphs of text. That's why there are also other concerns, like the following:

A change should be as atomic as possible

That's why this

let a = 1;            let a = 1;
let bb = 2;     >>    const bb = 2;
let ccc = 3;          let ccc = 3;

// one line changed

is better than that

let a   = 1,          let   a   = 1,
    bbb = 2,    >>          cc  = 3;
    cc  = 3;          const bbb = 3;

// three lines changed

If I don't have to change a lot of lines, refactoring is more fun. As a nice side-effect, git diff also becomes more readable.

Always use a trailing comma in a multiline list.

It makes manipulating lists more comfortable. And git diffs cleaner.

// Adding an item
const obj = {         const obj = {
  foo: true,            foo: true,
  bar: 'baz',   >>      bar: 'baz',
}                       hello: 'world', // only adding line here
                      }

// only one changed line

VS

// Adding an item
const obj = {         const obj = {
  foo: true,            foo: true,
  bar: 'baz'    >>      bar: 'baz', // adding comma here
}                       hello: 'world' // adding line here
                      }

// three changed lines

Recommendations

Disabling rules

Sometimes, there is a legitimate use-case to disable a specific rule. You can disable a rule for the current line like this

// eslint-disable-line rule-code

where rule-code is the code that is displayed along the error message.

In rare cases, it makes sense to disable a rule for the whole project. For instance, if you work with JSON data coming from a foregin API that uses underscore property names.

If you don't agree with a rule, please do not just disable the rule. It's better to create an issue here in order to discuss the pros and cons of a rule.

Should I apply --fix as part of my posttest script?

No. Because this way, eslint won't report all linting errors on Travis CI. Thus, a PR could contain linting errors without Travis CI complaining about it.

License

Unlicense

Based on the Standard ESLint config