Open Source Ruby Code Formatters

Pronto runs analysis quickly by checking only the relevant changes. Created to be used on GitHub pull requests, but also works locally and integrates with GitLab and Bitbucket. Perfect if you want to find out quickly if a branch introduces changes that conform to your style guide, are DRY, don't introduce security holes, and more. Pronto runs the checks on a diff between the current HEAD and the provided commit-ish (default is master). You can run Pronto as a step of your CI builds and get the results as comments on GitLab commits using GitlabFormatter. You can run Pronto as a step of your CI builds and get the results as comments on Bitbucket commits using BitbucketFormatter or BitbucketPullRequestFormatter. The behavior of Pronto can be controlled via the .pronto.yml configuration file.

RuboCop is a Ruby static code analyzer (a.k.a. linter) and code formatter. Out of the box it will enforce many of the guidelines outlined in the community Ruby Style Guide. RuboCop packs a lot of features on top of what you’d normally expect from a linter. Works with every major Ruby implementation. Autocorrection of many of the code offenses it detects. Robust code formatting capabilities. Multiple result for matters for both interactive use and for feeding data into other tools. Ability to have different configurations for different parts of your codebase. Ability to disable certain cops only for specific files or parts of files. Extremely flexible configuration that allows you to adapt RuboCop to pretty much every style and preference. It’s easy to extend RuboCop with custom cops and formatters. Many online services use RuboCop internally (e.g. HoundCI, Sider and CodeClimate).

The standard gem brings the ethos of StandardJS to Ruby. It's a linter & formatter built on RuboCop and provides an unconfigurable configuration to all of RuboCop's built-in rules as well as those included in robocop-performance. It also supports plugins built with lint_roller, like standard rails. Standard Ruby was created and is maintained by the team at Test Double, because we appreciate the importance of balancing predictable, consistent code with preserving developer autonomy. Yes, Standard is unconfigurable. See, pretty much every developer can agree that automatically identifying and fixing slow, insecure, and error-prone code is a good idea. People also agree it's easier to work in codebases that exhibit a consistent style and format. So, what's the problem? No two developers will ever agree on what all the rules and format should be.