|
| 1 | +# Use an opinionated set of rules for Rubocop |
| 2 | + |
| 3 | +Ruby code can be written in many different styles and still be syntactically correct. The presence of divergent style and |
| 4 | +format can disrupt communication as well as complicate feature development. Code that exhibits a consistent style is |
| 5 | +easier to understand and maintain. The absence of consistent enforced style can result in unnecessary code churn. |
| 6 | + |
| 7 | +**Therefore:** Use an opinionated set of rules for Rubocop when coding in Ruby. |
| 8 | + |
| 9 | +- Prefer [standard] for new projects. |
| 10 | +- By employing an already decided configuration, you avoid bikeshedding on what the Rubocop configuration should be. |
| 11 | +- Code that is consistently formatted and styled will be easier to work with. |
| 12 | + |
| 13 | +There are, however, a few reasons one might choose not to introduce Standard in a project: |
| 14 | + |
| 15 | +- Change for the sake of change can be disruptive |
| 16 | +- An existing project may already employ it's own opinionated configuration of Rubocop and that set of rules is working. |
| 17 | +- A large project, which does not already use Standard, might require a costly amount of time to refactor and retrofit |
| 18 | + existing code to conform to a new set of conventions. |
| 19 | +- There exists a need or desire to use Cops which are disabled by Standard |
| 20 | +- [standard] presents a lightweight but sensible set of style rules to focus on coding |
| 21 | +- [standard] prevents you from using cops that it disables |
| 22 | + |
| 23 | +Overall, the goal is to increase the quality and consistency of code while not getting distracted by disproportionally |
| 24 | +minor or trivial details. It's more important for an implementation team to agree to follow shared conventions than it |
| 25 | +is to enforce a specific configuration. |
| 26 | + |
| 27 | +[standard]: https://github.com/testdouble/standard |
0 commit comments