Code reviews zijn een krachtig middel om de kwaliteit en consistentie van code op een project te verhogen. Deze reviews kunnen worden gedaan door bijvoorbeeld andere ontwikkelaars op een project als peer-rievew. Maar we kunnen bepaalde zaken ook vinden en signaleren door het gebruik van code analyse tools. We kunnen voor Groovy code gebruik maken van een code analysis tool met de naam CodeNarc. CodeNarc is te vergelijken met Checkstyle, PMD of FindBugs dat we kennen voor Java code. CodeNarc maakt het mogelijk om geautomatiseerd regels los te laten op de source code. Afwijkingen op de regels worden gerapporteerd en eventueel wordt een alternatieve implementatie getoond.
CodeNarc heeft op dit moment 241 regels die we kunnen toepassen op onze Groovy code. De regels variëren van simpele syntax zaken tot naamgevingsconventie of specifieke implementatie regels. Naast de bestaande regels is het ook mogelijk om zelf regels nog aan te passen of nieuw aan te maken. Hierdoor is het mogelijk om voor onze eigen projecten de juiste set van regels te maken en toe te passen.
Laten we eens kijken wat CodeNarc kan signaleren in de volgende Groovy code:
package com.vxcompany
import java.text.*
import java.util.logging.*
class SampleClass {
private static final log = Logger.getLogger(Sample);
Double sum
Map results = new HashMap()
void setSumAsString(String value) {
try {
sum = NumberFormat.instance.parse(value)
} catch (ParseException parseException) { }
}
private def addTwo() {
return sum.plus(2)
}
boolean equals(other) {
sum.equals(other.sum)
}
String tostring() {
sum
}
}
De volgende figuren tonen de resultaten van de analyse die CodeNarc heeft uitgevoerd in de gegenereerde HTML rapportage:
We gaan eens in meer detail kijken naar de resultaten. Een duidelijke regel die overtreden wordt is EmptyCatchBlock. In de code zien we dat het try/catch blok in de methode setSumAsString(String) geen implementatie heeft in het catch gedeelte. Hierdoor wordt een eventuele fout bij het vertalen van de String waarde naar een Double niet doorgegeven aan de code die deze methode aanroept en zal de exceptie niet naar voren komen bij de uitvoering van de applicatie. We moeten wel iets zinnigs doen met de exceptie of gebruik maken van Groovy’s exceptie mechanisme, waarbij excepties automatisch vertaald worden naar run-time excepties. De EqualsAndHashCode regel kijkt of we een equals(Object) methode definiëren en als dat zo is dat we dan ook de hashCode() methode hebben geïmplementeerd. Het is erg verstandig om beide methoden te definiëren in een klasse, zodat een object van deze klasse goed te gebruiken is bij sorteren of als key in Map klassen.
CodeNarc bevat een hoop regels die specifiek kijken naar code om te zien of de code meer kan voldoen aan de Groovy syntax. Deze regels zijn erg handig voor ontwikkelaars met een Java achtergrond en nu Groovy code schrijven. CodeNarc geeft bij de regels meteen aan welke alternatieve Groovy syntax gebruikt kan worden. In ons voorbeeld zien we dat de regels ExplicitCallToEqualsMethod en ExplicitCallToPlusMethod aangeven dat we in plaats van methode aanroepen ook operators kunnen gebruiken.
ExplicitHashMapInstantiation geeft aan dat we de simpele syntax [:] kunnen gebruiken voor het aanmaken van een HashMap. En we zien hoe we in Groovy minder code hoeven te schrijven met de regels UnnecessaryDefInMethodDeclaration, UnnecessaryReturnKeyword en UnnecessarySemicolon.
Een groot voordeel van een analyse met een tool als CodeNarc is dat ook kleine typefouten of copy-paste foutjes ook ontdekt worden. Dit zijn vaak zaken die je met een handmatige code review over het hoofd kan zien. Was het bijvoorbeeld opgevallen dat de tostring() methode fout is gespeld? We bedoelen hier toString() en dat is ook wat de regel ObjectOverrideMisspelledMethodName aangeeft. De regel LoggerForDifferentClass geeft aan dat een Logger object wordt aangemaakt voor de Sample klasse, maar we bedoelen de SampleClass klasse. Deze fout kan bijvoorbeeld komen door het kopiëren van een stuk code uit een andere klasse en dan vergeten we de waarde aan te passen.
Wanneer we een tijdje bezig zijn met een applicatie kan het gebeuren dat we code hebben geschreven die niet meer wordt aangeroepen. In ons voorbeeld zien we met de regels UnusedPrivateField en UnusedPrivateMethod dat we een variabele en methode hebben gemaakt die helemaal niet worden aangeroepen. Deze code kunnen we dus rustig verwijderen.
We kunnen ook regels configureren, zodat we code richtlijnen en standaarden voor een project kunnen maken en toepassen op alle code. Denk bijvoorbeeld aan naamgeving van variabelen of het toevoegen van een copyright statement in de bron code. De regels FieldName en RequiredCopyright geven in ons voorbeeld aan dat we niet aan deze richtlijnen voldoen. De variabele naam voor het Logger object is een constante en de naam moet dan bestaan uit hoofdletters. Verder hebben we een specifieke regel geconfigureerd die kijkt of er een copyright statement in de code aanwezig is.
Het is mogelijk om bij het uitvoeren van CodeNarc op de code bepaalde regels te negeren. Allereerst kunnen we met een configuratie bestand aangeven welke regels we wel of niet willen toepassen. Verder kunnen we ook de prioriteit definiëren voor een regel. Deze configuratie is beschreven in een Groovy bestand.
In de bron code zelf kunnen we met de annotatie @SuppressWarnings opgeven dat een bepaalde regel genegeerd kan worden voor een stuk code. Hierdoor worden we niet lastig gevallen in de rapportage met zaken waarvan we weten dat ze een regel niet volgen, maar dat we dat ook niet erg vinden voor dit specifieke stuk code.
We hebben nu een klein gedeelte gezien van de regels die CodeNarc ondersteunt. Maar het is niet moeilijk om zelf regels te schrijven. Voor een eigen regel moeten we een visitor klasse maken die de Abstract Syntax Tree (AST) van de code kan doorlopen. De AST bevat alle code vlak voordat die gecompileerd gaat worden. We kunnen deze structuur bekijken en analyseren, zodat we weten of de code voldoet aan de door ons gestelde regels. De CodeNarc API bevat allerlei handige methoden waarbij we specifieke onderdelen van de AST kunnen bekijken en daar dan ook analyses op toe te passen.
Conclusie
De conclusie is dat CodeNarc een erg nuttige tool is om toe te passen op projecten met Groovy code. Er is ook een plugin voor Grails beschikbaar, zodat we ook CodeNarc voor Grails projecten kunnen gebruiken. De standaard regels die beschikbaar zijn zorgen ervoor dat we makkelijk kunnen leren hoe we code moeten schrijven die voldoet aan de Groovy syntax, maar ook hoe we betere klasse implementaties kunnen maken. Voor specifieke regels voor onze projecten kunnen we de regels ook configureren, zodat we bijvoorbeeld een standaard naamgevingsconventie binnen het project kunnen gebruiken. Naast het configureren van de regels, is het niet moeilijk om zelf nieuwe regels te maken en toe te passen binnen een project. CodeNarc is hiermee een uitstekende code analyse tool om te gebruiken.