This is a style guide for the Prism project. Its goal is to write clearer and more maintanable code throughout the production process.
- Javascript - Classes - Variables - Constants - Semi-colons - Functions - Files - Folders - Vue.js specifics
- Templates
- CSS / SCSS - Formatting - Variables - Nesting - Rules - order
Class names are written in camelCase and begin with an uppercase.
Example: ClassName
Complete example:
export default class ClassName extends OtherClass {
constructor(parameters) {
}
}
Variable names should be written in camelCase and begin with a lowercase. Declaring a variable should be done by using let
and not the var
keyword.
Example:
let variableName = value
let otherVariableName = value
They will be defined right after the import
section of the code and before declaring any variables. They will be written in snake_case and entirly in uppercase.
Example: const CONST_NAME = value
We will not use semi-colons in Javascript.
Check out this article: Semicolons aren't required
They will be named in camelCase starting with a lowercase. All parameters should be on the same line as well as the opening bracket. The function
keyword will not be used.
Example:
functionName(parameter1, parameter2, parameter3) {
//function's core
}
Files must be named in kebab-case with only lowercase caracters.
Example: my-file-name
The same rule applies for folders
Example: my-folder-name
Custom components, sections, transitions, directives... should be organised as such
.
├── _vuejs-component
| ├── vuejs-component.js
| ├── vuejs-component.html
| └── vuejs-component.scss
Examples:
Note: The folder and the file that are containing a class should have the same name than the class but with their respective rules.
- Use tabs (4 spaces) for indentation.
- Never mix spaces and tabs for indentation.
- Prefer dashes over camelCasing in class names.
- Do not use ID selectors.
- When using multiple selectors in a rule declaration, give each selector its own line.
- Put a space before the opening brace { in rule declarations.
- In properties, put a space after, but not before, the : character.
- Put closing braces } of rule declarations on a new line.
- Put blank lines between rule declarations.
Example :
.selector {
border-radius: 50%;
border: 2px solid white;
}
.one,
.selector,
.per-line {
// ...
}
Prefer dash-cased variable names (e.g. $my-variable
) over camelCased or snake_cased variable names. It is acceptable to prefix variable names that are intended to be used only within the same file with an underscore (e.g. $_my-variable
).
Do not nest selectors more than three levels deep!
.page-container {
.content {
.profile {
// STOP!
}
}
}
When selectors become this long, you're likely writing CSS that is:
- Strongly coupled to the HTML (fragile) —OR—
- Overly specific (powerful) —OR—
- Not reusable
-
Property declarations
List all standard property declarations, anything that isn't an
@include
or a nested selector. The properties should be grouped by type, example :.selector { /* Positioning */ position: absolute; z-index: 10; top: 50%; right: 50%; transform: translate(-50%, -50%); /* Display & Box Model */ display: inline-block; overflow: hidden; box-sizing: border-box; width: 100px; height: 100px; padding: 10px; border: 10px solid #333; margin: 10px; /* Text */ font-family: sans-serif; font-size: 1rem; line-height: 1.5; text-align: right; color: #fff; /* Color */ background: #000; fill: #123; /* Other */ cursor: pointer; /* Animations */ transition: all 2s ease; animation: my-keyframes 2s ease forwards; will-change: opacity; }
-
@include
declarationsGrouping
@includes
at the end makes it easier to read the entire selector. -
Nested selectors
Nested selectors, if necessary, go last, and nothing goes after them. Add whitespace between your rule declarations and nested selectors, as well as between adjacent nested selectors. Apply the same guidelines as above to your nested selectors.