Onderzoek Codestyle: linting, template, packages en overig - marcoFijan/projectTech GitHub Wiki

Linters

Om je code vast te houden aan een vast aantal regels, zijn er verschillende linters die je kunt gebruiken om je code netter te schrijven. Zo kun je bijvoorbeeld bepalen hoeveel en wat voor ruimte je wilt na elke inner function. Ik zelf vind het fijn om hier 2 spaces / 1 tab te hebben. Er zijn een paar linters die ik heb onderzocht. Als eerste vond ik ESLint

ESlint

Met ESlint kun je regels zetten die standaard waarschuwingen of errors geven. Je kunt ook instellen om deze standaarden automatisch te laten forceren via ESlint. Ikzelf vond dat in eerste instantie iets te risky en koos ervoor om alleen waarschuwingen en errors te geven. In de configfile van ESlint, staan er standaard geen rules aan. Maar met

"extends": "eslint:recommended"

kun je snel alle aanbevolen en veelgebruikte rules aanzetten. Daaronder, kun je nog apart met "rules": bepaalde rules overschrijven. Je kunt dan aangeven of je liever een warning of error ontvangt. Of je kunt de rule uitzetten. Daarnaast is het ook mogelijk om andere rules aan te zetten die standaard niet aan staan.

EslintIgnore

ESLint pakt standaard zoveel mogelijk bestanden die hij kan bereiken om daar waarschuwingen of errors te geven. Maar voor bepaalde folders en bestanden is het niet handig als ESLint hier overheen gaat scannen. Daar kun je een .eslintignore bestand voor aanmaken. Hierin geef je, net zoals bij .gitIgnore, aan welke folders en bestanden niet gescand moeten worden.

Editorconfig

Linters en de editorconfig werken hand in hand met elkaar. Met editorconfig kun je ook rules zetten zoals bij ESLint. ESLint, neemt die rules dan ook over voor in zijn instelling. Het voordeel van editorconfig is dat je hier eventueel speciale rules kunt zetten voor speciale bestanden. Zo kun je aangeven dat .MD (markdown) bestanden een andere indent-space hebben dan javascript bestanden.

Prettier

Uit verschillende bronnen kreeg ik te horen dat prettier beter en veiligere manier is om je code netter te formatten en de regels van ESLint te forceren. Ik heb de Prettier package geprobeerd, maar dit verliep niet soepel in combinatie met Atom. Ik heb er dus ook voor gekozen om ESLint en Editorconfig te gebruiken om regels te zetten. En de atom-package prettier te gebruiken om de rules te formatteren in mijn editor. Ik heb Prettier uiteindelijk dus niet meer als dependecy in mijn express-server.

Editors

Er zijn veel verschillende Editors te gebruiken. Ik gebruik nu al minstens een jaar Atom

Atom

Atom is een hele basic editor. Het voordeel van Atom is dat hij veel support heeft voor community packages. Met al die packages kun je je editor zo uitgebreid maken zoals je wilt. Inmiddels heb ik al aardig wat packages toegevoegd aan mijn Atom waardoor ik veel meer functionaliteiten heb. Zo heb je packages van mensen waarmee je veel dingen kan laten automatiseren of verbinding maken.

VS Code

Een andere populaire editor is VS Code. Eigenlijk zie je bij professionele webdevelopers altijd alleen maar Atom of VS Code. VS Code heeft het voordeel dat hij uit zichzelf al erg uitgebreidt is. Maar, je hebt ook een stuk minder community mods/packages die je kunt installeren.

Samengevat hebben beide code-editors de mogelijkheden om extra's te installeren. De ene (Atom) editor heeft weinig features uit zichzelf maar kan dit compenseren met de ontelbare packages. De ander (VS Code) heeft meer features uit zichzelf maar heeft minder instelbare packages. Wel heeft VS Code meer theme opties voor zowel de syntax als de UI.

Atom packages

Er zijn verschillende packages voor Atom. Hier zet ik de packages die ik handigst of belangrijkst vind. De allerbelangrijkste voor mij is Emmet:

Emmet

Met Emmet krijg je heel veel shortcuts voor het maken van een HTML page. Zo kun je op 1 regel een hele list opzetten. Of kun je met ! en een tab gelijk de HTML essentials opzetten (head, body, meta, etc). Emmet geeft heel veel functionaliteiten waar ik nu niet meer zonder mee zou kunnen.

Beautify

Met Beautify kun je makkelijk en snel je code HTML code formateren met de juiste indent en lines. Ik gebruik Beautify voor mijn HTML en ESLint voor mijn Javascript aangezien hier meer fouten kunnen ontstaan.

File icons

Een handige package die aan de zijkant laat zien wat voor bestanden je naast hebt staan. Dit geeft meer overzicht in een korte oogopslag.

Color-picker

Een package die makkelijk een colorwheel geeft wanneer ik een andere kleur wil kiezen.

Git-plus

Geeft een UI voor git waarmee je makkelijk je commits kan beheren en opsturen. Het echt pushen van data naar github kan echter alleen via de terminal.

Mini-map

VS Code heeft standaard een handige minimap waardoor je een klein overzicht hebt van je code. Deze package voegt ook zo'n minimap toe. Dit geeft meer overzicht en maakt navigeren ook makkelijker.

W3C-validator

De W3C-validator geeft standaard na elke save een veld onder aan je code met mogelijke errors. Hoewel ik dit erg handig vond voor veelgemaakte fouten. Is het de laatste tijd niet erg betrouwbaar meer geworden voor mij. Root variablen in CSS worden niet ondersteund. Dus elke keer als die variablen wordt geroepen, krijg ik een error. Daarnaast zijn mijn HTML bestanden ook niet meer te controleren door het gebruik van templating. Momenteel heb ik deze validator dus ook uitstaan.

Template Engines

Voordat ik begon met Template Engines had ik al erg veel HTML en CSS geschreven. Om het makkelijk te houden, koos ik al snel voor EJS. Met EJS is het overzichtelijker, voor iemand die bekend is met HTML, om variablen mee te nemen. Ik koos daarom al snel voor EJS. Ik heb daarnaast uiteraat ook de andere Template Engines onderzocht.

EJS

Met EJS kun je makkelijk in vrij korte code data ophalen uit een andere source:

<p><%= profiles[i].location %></p>

Op die manier kun je makkelijk via een javascript (en die weer via een database) unieke data ophalen. Hierdoor is het mogelijk om eerst een template te maken, en dan voor elke pagina, zoals een profielpagina, dezelfde template te gebruiken. Je gebruikt dan dus 1 template, en vult die meerdere keren opnieuw in met andere data uit een database. Een ander voordeel is dat je je HTML page kan opsplitsen. Een header, head, footer is altijd hetzelfde op elke pagina. Die kun je dus apart opslaan in een aparte template en dan die template-component oproepen in een hoofd-template:

<%- include('components/head.ejs') -%>

Hierdoor hoef je, wanneer je bijvoorbeeld een cloud font gebruikt of je je navigatiemenu wilt aanpassen, maar 1 bestand aan te passen. Namelijk de head.ejs of header.ejs.

Handlebars

Handlebars werken, net zoals alle andere template engines, erg hetzelfde als EJS. Bij handlebars roep je alleen de data anders op. Waar EJS <%=...%> gebruikt, gebruikt handlebars {{...}}. Dat ziet er dan dus bijvoorbeeld zo uit:

<p>{{firstname}} {{lastname}}</p>

Zelf vind ik dit persoonlijk minder overzichtelijk. In de template gebruik je de { ook regelmatig. Voor wanner ik een for loop wil maken bijvoorbeeld:

//EJS Voorbeeld
<% for (var i = 0; i < profiles.length; i++) { %>

In Handlebars zou dit er onoverzichtelijk uitzien als je de <% Gaat vervangen met {{

//Handlebars Voorbeeld
{{ for (var i = 0; i < profiles.length; i++) { }}

Hierdoor koos ik EJS boven handlebars

Nunjucks

Nunjucks is nog een voorbeeld. Nunjucks gebruikt {%..%} om data op te halen. Ook hier wordt weer gebruik gemaakt van de curly brackets { }. Maar dit keer zorgt de % wel voor een betere leesbaarheid naar mijn mening. Toch had ik me hiervoor al eerst goed ingelezen op EJS en persoonlijk vind ik het gebruik van < > in HTML fijner en logischer. Ik koos daarom opnieuw voor EJS.

Bronnen

⚠️ **GitHub.com Fallback** ⚠️