Solvedjavascript consider removing stylistic rules that can't be automatically fixed from eslint-config-airbnb

I'm dismayed at how often I have to fight with some of these rules in open-source projects that use them; to one who's used to automatic code formatters cleaning up things like indentation and spacing, having ESLint complain about nitpicky things with your code instead of just fixing them feels demeaning and inhumane.

I also think this is a concerning development in programmer culture given how ESLint now has much vaster nitpicking capability than any kind of automated analysis tools I've ever been aware of. It's like OCD on a mass, collective scale.

If a rule helps prevent bugs, okay, I get it, and I'm happy to comply with it. But manually fixing little stylistic issues that have nothing to do with preventing bugs, because ESLint doesn't yet support automatically fixing them? Come on, relax, it will be okay, get outside and remember there's more to life than slaving away like a robot whose only job is to produce absolutely perfect selfsame code.

As a popular, well-known company, you have the power to influence programmer culture and quality of life for better or worse with this ruleset and other tools you release; please consider their impact.

23 Answers

✔️Accepted Answer

Hi @jedwards1211, thanks for checking out the guide. We always appreciate feedback from the community. I totally get where your frustration is coming from--the joy comes from writing the code and making it work, not writing code to please the computer. Yet here we are letting the computer give us feedback on our code. Why are doing this? What's in it for me?

There's a lot in this issue, so let me back up a bit to some first principles we believe in before we get into your proposal.

  1. Linter-enforced style guides benefit teams & projects over time
    • The bigger your team gets and the more projects a codebase has, context switching becomes increasingly expensive. See #102 for a more in-depth example on the problem a team faces while maintaining codebase quality over time.
  2. Time-saving discussions for everyone
    • When any project adopts a lint step, it becomes much easier for maintainers to accept pull requests from contributors. Maintainers no longer have to comment or close a PR saying "please use 2 spaces" or "please add semicolons" which we've seen spiral out of control into issues about whether semicolons are moral or just in today's world.
    • The beauty of it is the contributor doesn't have to wait for the maintainer to respond with the necessary fixes--they get immediate feedback. The project moves forward faster and code quality stays consistent.
    • The discussion is focused solely on what the code does, the implementation details, next steps, etc.
    • As GitHub has made it easier for programmers to connect and collaborate around the world, this becomes increasingly important because projects now have 24/7 dev time. Why slow everything down waiting on humans to parse code?
  3. Forks encouraged, pull requests welcome
    • Let us know! Open an issue for specific rules that you feel are too nitpicky and we'll do our best to explain our reasoning or detail a way to disable it for your project.
    • The beauty of ESLint’s plugin system is that you can extend an eslint plugin config and turn off rules you disagree/don't care about, publish it on npm, and take it with you everywhere you go.
  4. Opinions all the way down
    • Many folks, such as yourself, can adapt to any code style and don't have a preference about nitpicky things. But there are others that can't stand it when brackets don't align or when their commit diffs look huge when they only added a new variable.
    • So how do we reconcile these two types of programmers? Let's agree on how we (team or project) write code, bring in a referee (the linter), and keep the conversation focused on feature, fix, or changeset.
    • There are a lot of strong opinions in this guide. We try to include our reasoning to help folks see why we made certain decisions. This guide has evolved over time and will continue to be updated as we learn new things. We try to publish new versions responsibly with SemVer and changelogs.
  5. Transition old codebases
    • Codemods are your friend. Check out this terrific post by @lencioni that details how to refactor an older base in an efficient way.

Now to the issue at hand! Your proposal to remove stylistic rules that can't be automatically fixed from eslint-config-airbnb.

With a linter we get the computer to do the boring work of pointing out stylistic issues. But we humans still have to go in and make the fixes. Feels like a half-measure. I agree. I also think eslint --fix and Codemods are getting better all the time and will help everyone make these changes efficiently and easily in the future. For example, ESLint 2.9.0 included some autofix improvements that lay the foundation for many more rules to be autofixed.

The real question is what do we do until the day we have the magic autofix?

Option 1: remove all the other rules and let the code run wild.

Good:

  • You run fix and be done with it.

Bad:

  • The code review discussions get messy because style opinions love to surface in a code review
  • Old parts of the codebase stay old since it's a lot of work to update them.
  • Team members slow down as they hop between projects and styles
  • PR review slows down

Option 2: keep the rules that can't be fixed as a bridge until the time that they can be autofixed

Good:

  • See 1-5 above

Bad:

  • It can feel like an uphill battle

For now, we see Option 2's benefits outweighing the downsides in this current bridge state we find ourselves in, but tools are getting better all the time.

So there's a light at the end of the tunnel! We'll get there.

Hope this helps explain the direction and motivation for this project. As always, we appreciate feedback.

Other Answers:

I think there is another benefit to enforcing a consistent style that @hshoff didn't mention. If code is stylistically hyper similar, your pattern recognition facilities work much better, which will allow you to more quickly spot bugs or know how to modify the code to make it do what you want. This is helpful for the author of the code, the reviewers of the changes, and future explorers who wish to understand how it works. Being able to quickly understand the code is very useful in this type of work, and having it all look exactly the same clears away a pile of tiny obstacles on that path.

TL;DR consistent code helps prevent bugs and increases productivity when writing and reviewing code (beyond preventing endless style discussions).

Put another way, some rules prevent bugs and the others prevent future bugs.

More Issues: