2010-05-19 15 views
7

Je viens de recevoir une nouvelle affectation qui me semble être un défi intéressant.Analyse de code statique pour la nouvelle langue. Où commencer?

Le client souhaite qu'un outil de vérification de style de code soit développé pour son langage de programmation interne (qui sera bientôt ouvert) qui s'exécute sur la JVM. La syntaxe du langage est très similaire à Java.

Le client veut essentiellement que je produise quelque chose comme checkstyle.

Donc ma question est la suivante, comment aborderiez-vous ce problème? Compte tenu d'une table rase quelles recommandations feriez-vous au client?

Je pense avoir 3 options

  1. Ecrire quelque chose à partir de zéro. Id préfèrent ne pas le faire car il semble que ce genre de problème d'outil d'analyse de code a été résolu tant de fois qu'il doit y avoir une approche plus orientée "framework" ou "platform".

  2. Fork un outil de vérification de style de code existant et modifier l'analyse syntaxique pour s'adapter à ce nouveau langage etc etc

  3. Étendre ou brancher un outil d'analyse de code statique existant. (Peut-être écrire un plugin pour Yasca?)

Répondre

4

Ces outils ont essentiellement pour mettre en œuvre un compilateur frontal pour au moins un sous-ensemble de la langue. Le point de départ le plus simple est souvent d'adapter une interface de compilation existante, vous devriez donc commencer par regarder le compilateur de votre client. Si vous êtes chanceux, il aura une séparation nette entre le front-end et le back-end et sera capable de l'utiliser tel quel et d'utiliser l'AST ou tout autre IR que le front-end produit pour effectuer votre analyse supplémentaire.

+0

Oui, ou utilisez un générateur d'analyseur si cela n'est pas possible. –

0

Jetez un oeil à FindBugs

+0

Yep, FindBugs, PMD checkstyle etc etc Les docs indiquent que sa extension, mais il semble que toute la magie est faite au niveau du code octet. Ainsi, dès la sortie de la boîte, cela peut détecter des problèmes dans le code d'octets généré, mais il peut alors être assez difficile de mapper ces erreurs sur le code source de ce nouveau langage. – tinny

1

Vous ne voulez pas écrire tout cela à partir de zéro. Voir le DMS Software Reengineeering Toolkit. Cela a généralisé des machines de compilateur pour l'analyse, la construction d'AST, la construction de tables de symboles, la construction/traversée de flux de contrôle et de graphiques de flux de données et d'arbres d'appels. DMS peut être obtenu avec une interface Java complète qui construit des AST, des tables de symboles et les analyses de flux ci-dessus. DMS gère les dialectes de langue avec aplomb, il devrait donc être aussi simple que possible de modifier ce front-end pour qu'il corresponde au langage Java de votre client tout en acquérant toutes ces machines d'analyse.

0

Qu'en est-il de PMD? J'ai utilisé PMD pendant des années, mais je n'ai jamais vraiment exploré son fonctionnement interne auparavant.

PMD peut être étendu en écrivant un analyseur de langue personnalisé, ce qui est fait en fournissant des implémentations de ce qui suit dans un fichier JAR sur le chemin de la classe.

net.sourceforge.pmd.cpd.Language
net.sourceforge.pmd.cpd.Tokenizer

http://pmd.sourceforge.net/cpd-parser-howto.html

Puis en utilisant le PMD rule designer je peux définir des règles de l'AST résultant.Ce qui me plaît dans PMD, c'est qu'il est un outil d'analyse de code largement reconnu dans l'espace Java et qu'il a donc beaucoup de support. E.g plugin Eclipse, Hudson CI plugin etc etc