title | position |
---|---|
Coding Styles |
5 |
In general terms, we agree with almost everything said in this blog post about GIT conventions and so should you. We only add/differ the following:
Commits should try to be as simple (atomic) as possible, but not simpler. Meaning you should always be able to revert specific fix
es, edit
s, update
s, add
s, and remove
s with git revert
We use eslint to check our code for the coding styles specified in the .eslintrc
file in the root of the app, you can configure your text editor to give you hints when you don't follow the styles.
- See .stylintrc file. More info: https://rosspatton.github.io/stylint1-0/
- For module specific styles, comply with
#unique-template-top-node-selector .my-generic-css-update { ... }
.classes
and#ids
should only be used to reference fromCSS
files. If you want to use some element fromJS
usedata-*
to always be sure where the element is referenced from.- For multiple, comma-separated selectors, place each selector on its own line.
- Attribute selectors, like
input[type="text"]
should always wrap the attribute's value in double quotes, for consistency and safety (see this blog post on unquoted attribute values that can lead to XSS attacks).