Questo implica un po 'di lavoro con pmd, ma credo che questo sia un caso valido per scrivere una regola personalizzata.
Il modo in cui le regole personalizzate in pmd funzionano è "compilare" il codice Java nella versione xml dell'albero dei simboli astratti e quindi eseguire query xpath su di esso.
Per avere un'idea della struttura, l'xml non tag è simile a:
class Example {
void bar() {
while (baz)
buz.doSomething();
}
}
viene "compilato" in:
CompilationUnit
TypeDeclaration
ClassDeclaration:(package private)
UnmodifiedClassDeclaration(Example)
ClassBody
ClassBodyDeclaration
MethodDeclaration:(package private)
ResultType
MethodDeclarator(bar)
FormalParameters
Block
BlockStatement
Statement
WhileStatement
Expression
PrimaryExpression
PrimaryPrefix
Name:baz
Statement
StatementExpression:null
PrimaryExpression
PrimaryPrefix
Name:buz.doSomething
PrimarySuffix
Arguments
Ad esempio: //WhileStatement[not(Statement/Block)]
identificherà while
istruzioni che non sono seguite da un'istruzione o un blocco con istruzioni - un blocco vuoto.
Mentre sarebbe necessario un po 'più di scavare nello specifico, è dovrebbe essere possibile scrivere la query xpath appropriata per identificare una decelerazione del metodo dove il tipo è qualcosa e che ha una dichiarazione di ritorno annidata sotto di essa che restituisce un null
. Scrivendo uno che contrassegna qualsiasi return null;
dovrebbe essere banale (un punto di partenza per perfezionare la regola). Ho scritto una regola pmd in passato (non ce l'ho più con me) che ha identificato static SimpleDateFormat ...
decelerations che potrebbe causare problemi dato che SimpleDateFormat non è thread-safe).
Se xpath non è abbastanza potente da identificare la regola specifica, è possibile scrivere una classe che viene collegata a pmd che otterrà l'AST e su di essa potranno essere apportate eventuali trasformazioni per identificare i problemi. Questo è un po 'più difficile da inserire in pmd (rispetto a una regola xpath).