Code Standards

We write code in a consistent style that emphasizes cleanliness and team communication.

Some of our high level guidelines:

• Be consistent.
• Don't violate a guideline without a good reason. (A reason is good when you can convince a teammate)
• Avoid inline comments when possible
• Break long lines after 80 characters
• Delete trailing whitespace
• Don't miszpell
• If you break up a hash, keep the elements on their own lines and closing curly brace on its own line
• A tab indent should be set to two spaces
• Indent continued lines one tab
• 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 }

Table Of Contents

• Naming Conventions
• HTML
• CSS

Naming Conventions

• As of April 2017 we are working towards all projects using BEM naming conventions for HTML/CSS
• Avoid abbreviations
• Avoid object types in names (user_array, email_method CalculatorClass, ReportModule)
• 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)

HTML Code Standards

• Always use Semantic Markup
• Approach the document with practicality over purity
• Prefer double quotes for attributes.
• Consistency and conventions between team members is paramount.
• Solutions should be as simple and clear as possible.
• Solutions should serve a specific purpose.
• Clever code does not mean good code; readability is critical
• Nested lists MUST NOT be more than 3 levels deep
• HTML attributes should come in this particular order for easier reading of code.

1. id, name
2. class
3. src, for, type, href, value
4. data-*
5. title, alt
6. role, aria-*

CSS Code Standards

• Use soft tabs with two spaces—they’re the only way to guarantee code renders the same in any environment
• When grouping selectors, keep individual selectors to a single line
• Include one space before the opening brace of declaration blocks for legibility
• Place closing braces of declaration blocks on a new line
• Include one space after : for each declaration
• Each declaration should appear on its own line for more accurate error reporting
• End all declarations with a semi-colon. The last declaration’s is optional, but your code is more error prone without it
• Comma-separated property values should include a space after each comma (e.g., box-shadow)
• Don’t include spaces after commas within rgb(), rgba(), hsl(), hsla(), or rect() values. This helps differentiate multiple color values (comma, no space) from multiple property values (comma with space)
• Do prefix property values or color parameters with a leading zero (e.g., 0.5 instead of .5 and -0.5px instead of -.5px)
• Lowercase all hex values, e.g., #fff. Lowercase letters are much easier to discern when scanning a document as they tend to have more unique shapes
• Use shorthand hex values where available, e.g., #fff instead of #ffffff
• Quote attribute values in selectors, e.g., input[type="text"]. They’re only optional in some cases, and it’s a good practice for consistency
• Avoid specifying units for zero values, e.g., margin: 0; instead of margin: 0px;