flyerhzm/rails_best_practices
64.1
Adequate · 28 September 2026
4.8k
lines of production code
Ruby
primary language
2
measurements over time
What this system is
This system is a static analysis tool for Ruby on Rails applications that enforces best practices and code quality standards. It operates by parsing application code, templates, and configuration to build a contextual model, which it then reviews against a suite of checks for issues like unused methods, missing database indexes, and style violations. The tool provides results via a command-line interface in multiple formats, including HTML reports with editor integration, and supports inline suppression of specific warnings.
How it got here
2009 — CLI introduction and engine refactoring
9 changes.
The project underwent a significant structural overhaul, introducing a dedicated command-line interface and replacing the custom analysis engine with the CodeAnalyzer gem. This period also involved standardizing the development environment, migrating documentation to Markdown, and removing legacy check implementations to support modern Ruby versions.
2010–2021 — Static analysis engine expansion and test coverage
13 changes.
This period focused on significantly expanding the static analysis capabilities of Rails Best Practices by introducing new preparer modules for building application context, lexical checks for code formatting, and numerous new reviews for enforcing best practices. The work was heavily supported by the addition of comprehensive RSpec test suites for the core engine, reviews, preparers, and lexical checks to ensure reliability. Additionally, the tool introduced an enhanced HTML report template with editor integration and improved ERB template processing.
Features
Added ERB template processing via Erubis extension
The system now includes a new core extension for handling ERB templates using the Erubis library. This addition introduces a custom \OnlyRuby\ class that modifies how template code is processed, specifically by stripping non-code characters during text addition and ensuring statements and expressions are terminated with semicolons, which affects how embedded Ruby code is parsed and rendered.
_lib/rails\_best\_practices/core\ext · high confidence
Added executable rails\_best\_practices CLI script
A new executable script has been added to the bin directory, allowing users to run the rails\_best\_practices tool directly from the command line. The script sets up the load path to include the local lib directory and requires the main library and command modules, enabling immediate usage of the tool's functionality.
bin · high confidence
New and updated code analysis reviews for Rails best practices
This release introduces several new static analysis reviews to enforce Rails best practices, including checks for adding model virtual attributes, ensuring database indexes on foreign keys, validating return values of save/destroy operations, and preventing the use of default\_scope. It also adds reviews to detect seed data in migrations, enforce the Law of Demeter, and identify unused methods in controllers and helpers. Existing reviews have been updated to support modern Rails patterns, such as recognizing strong\_parameters and Devise for mass assignment protection, handling polymorphic associations, and improving route customization checks.
_lib/rails\_best\practices/reviews · high confidence
New lexical checks for long lines, tabs, and trailing whitespace
The tool now includes three new checks in the Lexicals module to enforce code formatting standards. LongLineCheck flags Ruby files where lines exceed 80 characters (configurable via max\_line\_length). RemoveTabCheck detects and reports the use of tab characters, recommending spaces instead. RemoveTrailingWhitespaceCheck identifies lines with trailing spaces. These checks help maintain consistent and clean code style across projects.
_lib/rails\_best\practices/lexicals · high confidence
New preparer modules for static analysis context
Rails Best Practices now includes a suite of new 'prepare' modules that build a comprehensive internal model of the application before running reviews. These modules parse and remember controllers, models, mailers, helpers, routes, and configuration settings, enabling more accurate detection of unused methods, associations, and other best-practice violations. Specifically, the new code handles InheritedResources DSL, Mongoid/MongoMapper attributes, nested routes, and initializer configurations like ForbiddenAttributesProtection.
_lib/rails\_best\practices/prepares · high confidence
Removals
Removal of legacy check infrastructure and specific rule implementations
The base \Check\ class and several specific analysis rules (\MoveFinderToNamedScopeCheck\, \UseModelAssociationCheck\, \UseScopeAccessCheck\) have been removed from the \lib/rails\_best\_practices/checks\ directory. This eliminates the underlying framework for these specific code-smell detections and the checks themselves, meaning the tool will no longer report issues related to moving finders to named scopes, using model associations instead of manual ID assignment, or enforcing scope access for current user redirects.
_lib/rails\_best\practices/checks · high confidence
Behavioural changes
Initial project scaffolding and configuration standardization
The repository is initialized with a standardized development environment, including a \.ruby-version\ file specifying Ruby 4.0.3, a \.gitignore\ for build artifacts, and an \.rspec\ configuration for test execution. The project structure is formalized with a \CHANGELOG.md\ documenting versions up to 1.23.4, a \Guardfile\ for automated test running, and a comprehensive \rails\_best\_practices.yml\ defining the default set of code quality checks. Documentation is migrated from Textile to Markdown, and the build system is simplified by replacing Jeweler with Bundler gem tasks.
(repo-wide) · high confidence
New HTML report template with editor integration and VCS metadata
The HTML result output has been replaced with a new template that displays warnings in a table, including short filenames, line numbers, and messages. It now supports clickable links to open files directly in various editors (VS Code, Atom, Sublime Text, TextMate, mvim) and displays Git or Mercurial commit hashes and usernames when available. The report also includes client-side filtering via checkboxes to show/hide specific warning types.
assets · high confidence
Rails Best Practices analyzer restructured with new CLI and output formats
The \lib/rails\_best\_practices\ library has been refactored to introduce a dedicated CLI class (\lib/rails\_best\_practices/cli.rb\) and a new \OptionParser\ for handling command-line arguments, replacing the previous \command.rb\ entry point. The analyzer now supports multiple output formats including HTML, JSON, YAML, and XML, and allows users to disable specific checks via inline comments (e.g., \\# rails\_best\_practices: disable SomeCheck\). The file parsing logic has been updated to prioritize model and mailer files during the preparation phase, and the tool now supports additional template editors like VS Code and Sublime via HTML output options.
_lib/rails\_best\practices · high confidence
Refactor core analysis engine to use CodeAnalyzer and split processing into prepare and review phases
The core analysis engine has been restructured to replace the custom \CheckingVisitor\ and \Sexp\ extensions with the \CodeAnalyzer\ gem, fundamentally changing how checks are executed. The previous single-step \check\ method is now split into distinct \prepare\, \review\, and \lexical\ phases, allowing the system to first gather context (such as model associations, routes, and gem versions) before performing violation checks. This change introduces new core classes like \ChecksLoader\ for configuration-driven check instantiation, \Core::Methods\ for tracking method usage across classes, and \Core::Routes\ for parsing route definitions. Additionally, the \Error\ class now inherits from \CodeAnalyzer::Warning\ and supports displaying Git commit/username information, while template parsing for ERB, HAML, and Slim is handled via dedicated parsers within the runner.
_lib/rails\_best\practices/core · high confidence
Refactored library structure and added CLI support
The library has been restructured to replace the previous monolithic require with explicit dependencies on new modular components, including CodeAnalyzer, Colorize, Analyzer, Lexicals, Prepares, Reviews, InlineDisables, OptionParser, and a new CLI class. This change introduces a command-line interface (CLI) for the tool and organizes the internal logic into distinct modules for parsing, preparing, and reviewing code, while also adding a frozen\_string\_literal directive for Ruby 1.9+ compatibility.
lib · high confidence
Test coverage
Added test coverage for Rails Best Practices prepare modules; Added test coverage for RailsBestPractices core components; Added test coverage for multiple Rails best practices reviews; Added test fixture for NotUseRailsRootReview plugin; Added tests for Erubis::OnlyRuby core extension; Added tests for inline disable functionality; Added tests for lexical checks: long lines, tabs, and trailing whitespace; Added tests for the Analyzer class; Removed obsolete test files for MoveFinderToNamedScopeCheck and UseScopeAccessCheck; Updated RSpec configuration and test environment setup.
Dependencies
Rails Best Practices 1.23.4 dependency update and Ruby 4.0 compatibility
The gem has been updated to version 1.23.4, introducing several dependency changes to support modern Ruby environments. Notably, \ostruct\ is now an explicit runtime dependency to ensure compatibility with Ruby 4.0, and \require\_all\ has been upgraded to version 3.0. The tool also pins \code\_analyzer\ to version 0.5.5 and relies on \activesupport\ without strict version constraints. Development dependencies have been refreshed to include \guard\, \guard-rspec\, \pry\, and \coveralls\_reborn\ (replacing the previous coveralls integration), while the gemspec now explicitly declares the MIT license.
(dependencies) · high confidence
Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.
How this codebase got here
Score
- CAI 67 → 64 (-2.9)
- Rubric changed (rubric-2026.09.8 → rubric-2026.09.16) — scores are not directly comparable.
Lenses
- Code Health 99 → 99 (+0.0)
- Architecture 100 → 100 (-0.1)
- Maturity 54 → 57 (+3.1)
- Readiness 61 → 64 (+2.8)
- Security 94 → 87 (-7.3)
- Accessibility 62 (new)
Resolved (4)
- Documentation: no contributor guidance (README.md)
- Documentation: no installation or build instructions (README.md)
- Documentation: no usage examples (README.md)
- Off-boarding risk: anonymized user #1
New (5)
- Ambiguous overlap between generation and analysis. In a static analysis tool, 'analyze' is the core operation. 'generate' is ambiguous: does it generate the report (output) or generate the analysis results? Given the presence of explicit output_* methods, generate likely duplicates the intent of triggering the analysis phase or the full pipeline, creating confusion about whether it is a distinct step or a synonym for analyze.
- Inconsistent access pattern for properties. The class defines Property: Runner.base_path and Property: Runner.config_path in the metadata, but also exposes Method: Runner.base_path() and Method: Runner.config_path(). This suggests redundant accessors (both property and method) or a mismatch between the declared property and the actual method signature, leading to confusion on how to access these values.
- Inconsistent boolean method naming. Ruby convention dictates that boolean methods should end with ?. Having debug? (boolean) and debug (likely void/action) is acceptable, but if debug is intended to be a getter for the debug state, it conflicts with the ? convention. If debug is an action to enable debug mode, it is distinct, but the naming is confusingly similar to the boolean check.
- Inconsistent getter/setter pattern. Ruby typically uses url for both getter and setter (or url= for setter). Having url() as a getter and url(url) as a setter is non-idiomatic and inconsistent with standard Ruby conventions, making the API harder to use predictably.
- Off-boarding risk: anonymized user #1
Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.
Survey your own repository
flyerhzm/rails_best_practices was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.
About this page
- The score is its most recent published measurement, taken on 28 September 2026 at a pinned commit. It is not a live figure and does not change until the project is measured again.
- Measured at commit 775a5d6060aee2baacfec7c91a68c5a69e919fe2 — the exact code this score is about.
- Scored under rubric-2026.09.16 — the same rubric and the same method as every other entry in this index.
- Measured by watchdog.canine.dev using codehealth-analyzer preprod-2d9048c36d26.