Bij Pronamic vinden we de kwaliteit van code erg belangrijk. Alle WordPress thema’s en plugins die wij ontwikkelen zijn daarom ook zoveel mogelijk gebouwd volgens de WordPress Coding Standards richtlijnen. We gebruiken tools zoals de WordPress Coding Standards voor PHP_CodeSniffer-bibliotheek om dit te controleren. Daarnaast controleren we elk project nog op vele andere punten. In dit bericht een aantal command line one-liners waarmee bepaalde zaken gecontroleerd kunnen worden.
Geen vendor prefixes in SASS-bestanden
We hebben bij de Pronamic de richtlijn dat er binnen SASS-bestanden geen vendor prefixes zoals -webkit-, -moz-, -o-, etc. worden gebruikt. Deze worden namelijk bij veel van onze WordPress projecten wel toegevoegd via een Grunt autoprefixer taak. Om te controleren of er inderdaad geen vendor prefixes worden gebruikt in de SASS-bestanden kan het volgende commando gebruikt worden:
grep --recursive --include="*.scss" --line-number --extended-regexp "\-(webkit|moz|o|ms)\-" src/sass
Font Awesome gebruik met fa-icon mixin
Bij veel WordPress projecten maken we gebruik van Font Awesome, een erg uitgebreid iconen font. Vaak voegen we Font Awesome toe aan WordPress projecten met behulp van Bower bower install fontawesome --save. Hierdoor kunnen we ook gebruik maken van de Font Awesome SASS-bestanden met bijvoorbeeld de mixins en variabelen. We proberen het gebruik van Font Awesome dan ook zoveel mogelijk op de juiste SASS manier te doen.
.test {
@include fa-icon();
content: $fa-var-angle-right;
}
Door te werken met de Font Awesome SASS-variabelen is het duidelijker welk icoon gebruikt wordt, $fa-var-angle-right zegt immers veel meer dan "\f105". Om te controleren of Font Awesome inderdaad op de juiste manier wordt gebruikt gebruiken we de volgende commando’s:
grep --recursive --include="*.scss" --line-number "FontAwesome" src/sass
grep --recursive --include="*.scss" --line-number "\\\f[[:digit:]]*" src/sass
Geen protocol relatieve URL’s
Met de ontwikkelingen en groei van https:// werd ook gezocht naar oplossingen om verbindingen via http:// en/of https:// te laten verlopen. In het verleden werd wel geadviseerd om te werken met protocol relatieve URL’s (bijvoorbeeld: //fonts.googleapis.com i.p.v. https://fonts.google.com/). Nu https:// voor iedereen wordt aangeraden en er vrijwel geen performance issues meer zijn is dit echter een anti-pattern. Met behulp van de volgende one-liner kan er gecontroleerd worden of er nog protocol relatieve URL’s worden gebruikt:
grep --recursive --include="*.php" --exclude-dir={bower_components,node_modules,vendor} "'//" .
Geen onnodige lege regels
De WordPress PHP Coding Standards hebben geen hele duidelijke regels qua regelgebruik, maar het onnodig gebruik van lege regels is in principe niet nodig. Met behulp van het volgende commando kan gecontroleerd worden of er in PHP-bestanden ook 2 lege regels elkaar opvolgen:
pcregrep --multiline --line-number --recursive --include=".*.php" --exclude-dir={bower_components,deploy,node_modules,vendor} "\n\n\n" .
Geen HTML-entities gebruikt
Doordat WordPress volledig UTF-8 is hoeft er in principe niet gewerkt te worden met HTML-entities. Met de volgende 2 commando’s kan gecontroleerd worden op het gebruik van HTML-entities:
grep --recursive --include="*.php" --exclude-dir={bower_components,deploy,node_modules,vendor} "&[[:alnum:]]*;" .
grep --recursive --include="*.php" --exclude-dir={bower_components,deploy,node_modules,vendor} "&#[[:digit:]]*;" .
Dit was een kleine selectie van commando’s die we gebruiken om de kwaliteit van onze producten te controleren. Ben je zelf ook een WordPress ontwikkelaar en gebruik je handige tools voor het controleren en waarborgen van de kwaliteit dan horen we dat graag. Laat gerust een reactie achter.