We follow https://github.com/standard/standard#the-rules to write JS.
The linter is configured to follow these rules too.
We follow https://en.wikipedia.org/wiki/JSDoc to write doc blocks
https://vuejs.org/v2/style-guide/
We follow main principals from the Idiomatic Style Manifesto but if some of them conflict with the JavaScript Standard Rules - the Standard wins.
Most useful parts of it are: Type checking and Conditional Evaluation
- We use SCSS preprocessor http://sass-lang.com/
- Avoid putting style inside Vue components
-
variable name - should be noun. The variable name should clearly and briefly explain what a variable exactly stores. Don't use the "Hungarian notation" identifiers names.
-
function name - should be a verb or should start with verb. Function names should be written in English using camelCase. The function name should clearly and shortly explain what the function exactly does.
-
Cases:
functionNamesLikeThis
variableNamesLikeThis
ConstructorNamesLikeThis
ClassNameLikeThis
EnumNamesLikeThis
methodNamesLikeThis
SYMBOLIC_CONSTANTS_LIKE_THIS
- Other naming related recommendations
// string
const dog = '...'
// array
const dogs = []
- Single-line comments one line above the code
- Multi-line comments are also welcome
- Avoid comments at the end of the line
Component/instance options should be ordered consistently.
This is the default order we use for component options. They're split into categories, so you'll know where to add new properties.
- Side Effects (triggers effects outside the component)
el
- Global Awareness (requires knowledge beyond the component)
name
parent
- Component Type (changes the type of the component)
functional
- Template Modifiers (changes the way templates are compiled)
delimiters
comments
- Template Dependencies (assets used in the template)
components
directives
filters
- Composition (merges properties into the options)
extends
mixins
- Interface (the interface to the component)
inheritAttrs
model
props
/propsData
- Local State (local reactive properties)
data
computed
- Events (callbacks triggered by reactive events)
watch
- Lifecycle Events (in the order they are called)
- Non-Reactive Properties (instance properties independent of the reactivity system)
methods
- Rendering (the declarative description of the component output)
template
/render
renderError
- Use actions only if you need wrap some mutation with some async logic. Don't just duplicate a mutation with an action.
- Use getter only if it returns some computed value and don't use it if in case it just returns state value
- We follow GitFlow process https://danielkummer.github.io/git-flow-cheatsheet/
- We do code review via Pull Request in GitHub/Gitlab/Bitbucket
Prefer ES6 syntax over older ES versions
[Recommendation] Prefer functional approach when possible