2010-07-14 7 views
0

Existe-t-il un moyen de nettoyer automatiquement/afficher les propriétés inutilisées dans un fichier messages.properties, ce fichier est énorme atm, mais le système a beaucoup changé et certains d'entre eux ne sont pas utilisés, le faire par la main prendrait beaucoup de temps dans l'inspection du code, et personnellement je n'aime pas avoir du gaspillage, des suggestions?clean messages.properties

pour vous mettre dans le contexte im travaillant sur un projet de couture, mais cela pourrait être valable pour d'autres projets java

Répondre

2

Non, il n'y en a pas. Et oui, c'est vraiment l'une des tâches/responsabilités pour lesquelles vous êtes payé. Pour faciliter la maintenance maintenant et dans le futur, j'utilise moi-même une convention orientée arbre dans la saisie des messages, de sorte que je (et mes successeurs) puisse facilement corréler l'emplacement/l'utilisation des messages du côté de la vue. Un peu dans le style de pagename.parentid.childtype.childname.attributename

E.g. une clé home.login.label.username.tooltip qui pointe vers un home.jsp avec:

<form id="login"> 
    <label for="username" title="${text['home.login.label.username.tooltip']}"> 

Gardez toujours cette convention et vous trouverez qu'il devient plus facile de maintenir tout cela.

L'accès aux propriétés de journalisation ne va pas être une aide rapide. Vous finirez par perdre plus de temps.

1

Je ne trouve pas d'outil pour cela et je ne crois pas que leur existe un 100% correct. Vous pouvez écrire votre propre analyseur qui recherchera tous les fichiers sources pour toutes les clés de message. Comme vous les trouvez, vous pouvez supprimer de la liste, pour progresser plus rapidement.

Ceux qui restent doivent être vérifiés manuellement.

Cependant, cela vous fera gagner beaucoup de temps.

+0

Ceci est l'approche que j'utiliserais, mais une chose qu'il ne serait pas en compte les cas où est la clé de message est construit dynamiquement –

+0

construit Dynamiquement en utilisant d'autres clés de message, non? Dans ce cas, si les "sous-clés" semblent être utilisées, le message construit doit également être conservé. Est-ce que je manque quelque chose? – thelost

2

Je pense que le chemin à parcourir serait d'écrire un wrapper autour d'un objet Properties afin que vous puissiez instrumenter (c'est-à-dire consigner) tous les accès aux propriétés de cet objet. Exécutez votre programme à travers ses opérations normales, puis analysez votre journal pour savoir quelles propriétés ont été réellement utilisées.

Pour affiner, vous pouvez étendre l'objet Properties avec un pointage qui conserve la trace de l'utilisation en lui-même, et une méthode qui écrit toutes les propriétés utilisées dans un fichier à votre demande. Cela vous éviterait d'avoir à manipuler le fichier journal.

+1

Sauf que, par volume, la plus grande utilisation des propriétés est l'externalisation des messages (ce qui est pertinent compte tenu du nom de fichier du demandeur, 'messages.properties'), et une grande partie de ces messages est généralement un message d'erreur. Donc, l'exécution de votre programme à travers "ses opérations normales" sera terriblement insuffisante. –

0

Si vous avez accès à bash (sur Windows, vous faites si vous installez Git, sur Mac/Linux, vous l'avez déjà) alors ce petit one-liner peut faire un travail moitié-décent de restreindre la recherche:

YOURPROPS=messages.properties 
SRCDIR=src 
egrep -v "($(
    cut -s -d = -f 1 <$YOURPROPS | 
     while read prop; do 
      grep -q -d recurse '"'"$prop"'"' $SRCDIR && echo "$prop"; 
     done | xargs echo | sed 's/ /|/g'))" $YOURPROPS | cut -s -d = -f 

(Cela suppose toutes les propriétés sont écrites comme name=value sans espace supplémentaire autour du signe égal, que vous utilisez signe égal plutôt que deux points ou de l'espace pour le séparateur, etc.)

Il va afficher toutes les propriétés qui n'apparaissent pas entre guillemets dans les fichiers $SRCDIR. Cela signifie que cela peut donner des faux positifs. Par exemple, si vous avez quelque chose comme ceci:

String msg = I18n.getString("foo.bar." + "baz"); 

... il pense que la propriété foo.bar.baz ne figure pas dans le répertoire source. Mais comme je l'ai dit, cela permet de réduire un peu la recherche.

0

Ce projet Open Source révolutionne le concept des fichiers de langue. Vous maintenez un fichier XML structuré avec toute la traduction. Le plugin i18n-maven créerait alors automatiquement les fichiers de propriétés. Vous pouvez également créer une classe d'accesseurs Java pour accéder aux clés. Vous pouvez utiliser un autre outil de vérification de code pour trouver des méthodes d'accès inutilisées. Voir: https://github.com/hoereth/i18n-maven-plugin/blob/master/doc/README_JAVA.md