4 ms·

Writing custom ESLint rules for your picky developers

13 points by egillie 9y ago

bjterry 9y ago
One danger of having a bunch of custom eslint rules is that you may be papering over weak abstractions in your codebase. Sometimes it's a problem with lack of macros (or a powerful type system) but other times rethinking the way you are using libraries can be a bigger win for maintainability.
- dmnd 9y ago
  Right on. Flexport definitely has few custom rules that address things that would be better solved by nicer abstractions. One great thing about lint rules though is that it's usually pretty easy to apply them to all existing code. That means you get the benefit of finding problems in older code without having to refactor into better abstractions or types. Also: hi, BJ :)
hamstercat 9y ago
Sometimes writing a custom rule makes sense, but it should be an exception and not the rule. Otherwise, you risk creating a sub-dialect only your team knows. That becomes a problem both for new hires, which have to take more time to ramp up, and for current dev switching jobs as they'll have a hard time abandoning what they learned. That's why I like sticking as close as possible to AirBnB's guide[0], not because it's better than anything else, it's just that most developper seem to agree on it and it's familiar to most dev. [0]: https://github.com/airbnb/javascript https://github.com/airbnb/javascript
benologist 9y ago
Setting up https://standardjs.com https://standardjs.com to format on save really helped me overcome my pointless formatting preferences, although gofmt was the catalyst.
wildpeaks 9y ago
Rather than trying to impose one style over another, (or worse, pretending one is standard and everyone else is wrong), it saves time to just let your devs set their editors to automatically open in the style they think best with (because the reason picky devs argue about syntax is to avoid frustration and losing focus when reading code), and let the commit hook format back to a common style. Tools help you get the job done, not get in the way.

13 points by egillie 9y ago

One danger of having a bunch of custom eslint rules is that you may be papering over weak abstractions in your codebase. Sometimes it's a problem with lack of macros (or a powerful type system) but other times rethinking the way you are using libraries can be a bigger win for maintainability.

dmnd 9y ago
Right on. Flexport definitely has few custom rules that address things that would be better solved by nicer abstractions. One great thing about lint rules though is that it's usually pretty easy to apply them to all existing code. That means you get the benefit of finding problems in older code without having to refactor into better abstractions or types. Also: hi, BJ :)

hamstercat 9y ago

Sometimes writing a custom rule makes sense, but it should be an exception and not the rule. Otherwise, you risk creating a sub-dialect only your team knows. That becomes a problem both for new hires, which have to take more time to ramp up, and for current dev switching jobs as they'll have a hard time abandoning what they learned. That's why I like sticking as close as possible to AirBnB's guide[0], not because it's better than anything else, it's just that most developper seem to agree on it and it's familiar to most dev. [0]: https://github.com/airbnb/javascript https://github.com/airbnb/javascript

benologist 9y ago

Setting up https://standardjs.com https://standardjs.com to format on save really helped me overcome my pointless formatting preferences, although gofmt was the catalyst.

wildpeaks 9y ago

Rather than trying to impose one style over another, (or worse, pretending one is standard and everyone else is wrong), it saves time to just let your devs set their editors to automatically open in the style they think best with (because the reason picky devs argue about syntax is to avoid frustration and losing focus when reading code), and let the commit hook format back to a common style. Tools help you get the job done, not get in the way.