In dit document zijn alle regels die wij hebben opgesteld om alle code zo consistent mogelijk te houden te lezen.

• Naamgevingen
  • Bestanden
  • SCSS bestanden
  • Classes en id's
  • JavaScript
  • Git branches
• Linters
  • ESLint
  • Stylelint

Om alle code consistent te houden hebben we ook regels opgesteld voor naamgevingen. Denk hierbij aan bestanden, SCSS files, CSS classes en id's, JavaScript (JS) code en Git branches. Ook houden wij alle code Engels-talig om het toegankelijk te houden voor iedereen.

Voor bestanden hebben wij afgesproken om alleen kleine letters te gebruiken en spaties te vervangen door een underscore _.

Bijvoorbeeld: file_name.js, file_name.png.

Met uitzondering van ejs betanden in verband met de leesbaarheid van de URL's. Deze worden op de volgende manier geschreven: file-name.ejs.

Voor alle SCSS bestanden wordt dezelfde werkwijze toegepast als bij de bestanden alleen zal een bestand ook beginnen met een underscore _.

Bijvoorbeeld: _file_name.scss.

Met uitzondering van index.scss waar alle SCSS bestanden in geïmporteerd worden.

Voor alle classes en id's houden wij de BEM methode aan. Dit houd in dat we alle classes en id's op de volgende manier schrijven: block--modifier-value.

<button class="button">
	Normal button
</button>
<button class="button button--state-success">
	Success button
</button>
<button class="button button--state-danger">
	Danger button
</button>

.button {
	display: inline-block;
	border-radius: 3px;
	padding: 7px 12px;
	border: 1px solid #D5D5D5;
	background-image: linear-gradient(#EEE, #DDD);
	font: 700 13px/18px Helvetica, arial;
}
.button--state-success {
	color: #FFF;
	background: #569E3D linear-gradient(#79D858, #569E3D) repeat-x;
	border-color: #4A993E;
}
.button--state-danger {
	color: #900;
}

Bij het maken van JavaScript (JS) variabelen, functies en methodes passen wij camelCasing toe.

Voorbeeld: functionName.

Voor Git branches hebben wij afgesproken dit als volgt te noteren: eerste3LettersVanIssueLabel_labelNummer_naam. Waarbij bij de naam alle spaties ook underscores _ zijn. Daarnaast passen we ook hier Engels toe.

Voorbeeld: dev_01_branch_name.

Door gebruik te maken van linters zorgen wij ervoor dat al onze code regels die we hebben afgesproken automatisch worden gecontroleerd tijdens het coderen met het commando npm run dev:watch.

Hieronder is te lezen welke linters wij hebben gebruikt en wat de regels zijn die wij opgesteld hebben.

ESLint gebruiken wij in dit project om ervoor te zorgen dat onze code consistent blijft. Hiervoor hebben wij de volgende regels opgesteld:

1. 4 indents (tab)
2. enkele quotes
3. semicolon aan het einde van een regel code
4. maken gebruik van ES6

Deze zijn allemaal verwerkt in een config file:

{
    "env": {
        "browser": true,
        "es6": true
    },
    "extends": [
        "eslint:recommended"
    ],
    "globals": {
        "Atomics": "readonly",
        "SharedArrayBuffer": "readonly"
    },
    "parserOptions": {
        "ecmaVersion": 11,
        "sourceType": "script",
        "ecmaFeatures": {
            "globalReturn": true
        }
    },
    "rules": {
        "indent": [
            "error",
            4
        ],
        "linebreak-style": [
            "error",
            "unix"
        ],
        "quotes": [
            "error",
            "single"
        ],
        "semi": [
            "error",
            "always"
        ],
        "no-undef": "off",
        "no-unused-vars": "off",
        "no-useless-escape": "off"
    }
}

Naast de regels die vastgelegd zijn via ESLint, hebben wij ook nog een paar mondelinge afspraken waarvan het niet mogelijk was om dat te verwerken in ESLint. Dit zijn:

1. Voor callbacks gebruiken we een arrow function.
2. Bij gewone functies zetten we er function voor.

app.get('/spotifylogin', (req, res) => {
    ...
});

function search (param) {
    console.log('joe');
}

Om onze SCSS code consistent te houden hebben we ervoor gekozen om ook hiervoor gebruik te maken van een linter. De linter die wij hebben gekozen is: Stylelint. Wij hebben voor deze linter gekozen omdat hij overzichtelijker en makkelijker te configureren is voor SCSS dan bijv. Prettier of ESLint.

Hiervoor hebben we voornamelijk de regels die in de stylelint-config-sass-guidelines zijn opgesteld aangehouden. De belangrijkste regels hieruit zijn:

1. een SCSS bestand eindigt altijd met een nieuwe regel.
2. bij het schrijven met decimale getallen die beginnen met een 0, kan deze weggelaten worden (bijv. .5em ipv 0.5em).
3. Hex kleuren worden met hoofdletters geschreven (bijv. #8BD5D5 ipv #8bd5d5).
4. Bij korte notaties van properties mogen geen waardes onnodig dubbel staan (bijv. 1em auto 0 ipv 1em auto 0 auto).

Verder hebben wij zelf nog de regel toegevoegd dat er gewerkt moet worden met 4 indents (tab).

{
    "extends": "stylelint-config-sass-guidelines",
    "rules": {
        "indentation": 4,
        "max-nesting-depth": null,
        "selector-max-compound-selectors": null,
        "order/properties-alphabetical-order": null
    }
}