4 ms·
The solution is the same as in many other programming languages: adopt a coding standard and enforce it in an automated fashion, i.e. in the CI/CD pipeline. Cod
by tomthecreator 6y ago
The solution is the same as in many other programming languages: adopt a coding standard and enforce it in an automated fashion, i.e. in the CI/CD pipeline. Code style then becomes mostly a non-issue and not an object of discussion.
In the case of Ruby:
* most popular style guide: https://rubystyle.guide/ https://rubystyle.guide/
* automated tool for linting and enforcing code style: https://rubocop.org/ https://rubocop.org/
- deleted 6y ago[deleted]
- pelasaco 6y agoI just would like to point out that even though that is the most sane way, it comes with it owns set of problems. One of them is when developers start to code to cheat the linter, or they complicate the code just to "make the linter happy", another is when the linting rule introduces problems/errors like https://github.com/rubocop-hq/rubocop-rails/issues/418 https://github.com/rubocop-hq/rubocop-rails/issues/418
- msbarnett 6y agoYeah I would never recommend relying on just a linter. The linter can reduce scut work, but you always want to have at minimum a thorough code review process that’s looking at things like “ok, we made the linter happy; but are we happy with the result, or should we have just disabled the linter here?” and “the linter didn’t catch that we solved this thing with X here but with Y&Z last time. Let’s rationalize our approaches and get everything on the same page”
- pelasaco 6y agoyes, well that's in the ideal world. In the reality, the "linter said so" is said sadly quite often.