Latest commit 5df1e8f Sep 7, 2016 @thorncp thorncp [Rubocop] Disable FrozenStringLiteralComment
RuboCop, somewhat recently, added the
[Style/FrozenStringLiteralComment][1] cop, which enforces the presence
of the `# frozen_string_literal: true` pragma at the top of every file,
when running in Ruby 2.3 mode. Hound recently [configured][2] RuboCop to
run in Ruby 2.3 mode by default. This means Hound will now comment on
any Ruby file touched in a PR that doesn't have the pragma, with:

> Missing frozen string literal comment.

This is intended to prepare code bases for Ruby 3.0, where strings will
be frozen by default. In practice, I find Hound making these comments to
be quite annoying, and I have disabled it on my current project.

It seems we can disable the cop, or start putting the pragma at the top
of all our files. The former seems easier so it's my pick.

[1]: bbatsov/rubocop#2542
[2]: houndci/linters#65

README.md

Style

A guide for programming in style.

Use Hound to automatically review your GitHub pull requests for style guide violations.

In addition to the general guidelines below, we also have the following more detailed, language/framework-specific style guides:

Formatting

  • Avoid inline comments.
  • Break long lines after 80 characters.
  • Delete trailing whitespace.
  • Don't include spaces after (, [ or before ], ).
  • Don't misspell.
  • Don't vertically align tokens on consecutive lines.
  • If you break up a hash, keep the elements on their own lines and closing curly brace on its own line.
  • Indent continued lines two spaces.
  • Indent private methods equal to public methods.
  • If you break up a chain of method invocations, keep each method invocation on its own line. Place the . at the end of each line, except the last. Example.
  • Use 2 space indentation (no tabs).
  • Use an empty line between methods.
  • Use empty lines around multi-line blocks.
  • Use spaces around operators, except for unary operators, such as !.
  • Use spaces after commas, after colons and semicolons, around { and before }.
  • Use Unix-style line endings (\n).
  • Use uppercase for SQL key words and lowercase for SQL identifiers.

Naming

  • Avoid abbreviations.
  • Avoid object types in names (user_array, email_method CalculatorClass, ReportModule).
  • Prefer naming classes after domain concepts rather than patterns they implement (e.g. Guest vs NullUser, CachedRequest vs RequestDecorator).
  • Name the enumeration parameter the singular of the collection.
  • Name variables created by a factory after the factory (user_factory creates user).
  • Name variables, methods, and classes to reveal intent.
  • Treat acronyms as words in names (XmlHttpRequest not XMLHTTPRequest), even if the acronym is the entire name (class Html not class HTML).
  • Suffix variables holding a factory with _factory (user_factory).

Organization

  • Order methods so that caller methods are earlier in the file than the methods they call.
  • Order methods so that methods are as close as possible to other methods they call.