A guide for programming in style.
In addition to the general guidelines below, we also have the following more detailed, language/framework-specific style guides:
- 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.
- Avoid abbreviations.
- Avoid object types in names (
user_array,email_methodCalculatorClass,ReportModule). - Prefer naming classes after domain concepts rather than patterns they
implement (e.g.
GuestvsNullUser,CachedRequestvsRequestDecorator). - Name the enumeration parameter the singular of the collection.
- Name variables created by a factory after the factory (
user_factorycreatesuser). - Name variables, methods, and classes to reveal intent.
- Treat acronyms as words in names (
XmlHttpRequestnotXMLHTTPRequest), even if the acronym is the entire name (class Htmlnotclass HTML). - Suffix variables holding a factory with
_factory(user_factory).
- 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.