Une classe à 1 dollar

Les conventions de nommage ont leur raison d'être : en Javascript, on sait immédiatement qu'uneFonction n'est pas la même chose qu'UneFonction, la seconde étant convenue d'être appelée avec l'opérateur new et surtout pas la première.

En Java une constante s'écrit en majuscules avec des soulignés en guise de séparateur entre les mots, et les noms des classes en camel-case avec la première lettre en majuscule. Attention, on parle bien de conventions, à savoir des bonnes pratiques à utiliser mais qui, si elles ne sont pas suivies, ne donnera pas un code incorrect. Par contre, en ce qui concerne la revue de code, ça risque de coincer aux entournures surtout si vous utilisez un outil tel que checkstyle dans votre build.

On pourrait égrainer l'ensemble des règles spécifiques à chaque langage, au bout d'un moment on reste face à ses choix : comment nommer une interface et la classe qui l'implémente ? Mon choix porte sur la classe à 1 dollar... je vais expliquer pourquoi.

La notation hongroise

La notation hongroise c'est ce truc qui a été inventé pour ajouter dans le nom des variables et des fonctions un code qui informe du type ou de l'intention de l'usage. Par exemple bWarning pour un booléen, ou idxItem pour nommer l'index d'un item dans un tableau. Bien que cela fût utile en son temps, ce style de notation est complètement dépassé surtout en Java ou le type des données est très marqué.

Cependant, on trouve encore du code avec un _ devant le nom d'une variable privée, alors qu'elle est déjà notée privée par le mot clé private (notez en passant que l'usage de _ en Java 9 sera proscrit).

On rencontre aussi ISomeInterface pour nommer une interface. Les mauvaises habitudes ont la vie dure, et je soupçonne les nouveaux développeurs sortant de l'école ayant épousé cette pratique d'avoir eu un professeur qui est plus âgé que moi.

Soyons sérieux 5 minutes, si vous nommez une interface ISomeInterface, pourquoi ne pas aller au bout de la logique en nommant vos méthodes mSomeMethod et vos classes CSomeClass ???

Non, définitivement, vos interfaces doivent s'appeler SomeInterface ; vérifiez dans la Javadoc, il n'y en a pas une qui commence avec un I surnuméraire : évitez d'utiliser un nom horrible pour une interface.

La notation américaine

Bien, maintenant que nous avons adopté SomeFeature pour nommer une interface, comment nommer une classe qui l'implémente ?

Avec un peu de chance, il y aura plusieurs implémentations et leur nom sera suffisamment significatif pour les distinguer les uns des autres. Par exemple :

Protocol     // c'est le nom de notre interface
HttpProtocol // c'est le nom d'une implémentation avec sa propre caractéristique
FtpProtocol  // c'est le nom d'une autre implémentation avec une autre caractéristique

Dans la vraie vie, on se trouve souvent dans un autre cas de figure, celui qui offre une implémentation par défaut de notre interface SomeFeature, voire d'une implémentation partielle qui sert de base à de possibles extensions. On ne peut pas nommer cette classe SomeFeature, le nom est déjà pris, fusse-t-il dans un package séparé, cela deviendrait confusant (j'aime bien les néologismes).

Alors, parfois on trouvera SomeDefaultFeature, et le plus souvent SomeFeatureImpl. Cette fois-ci, c'est la classe qui a un nom horrible.

Foutu pour foutu, je me suis inspiré du style de nommage que Java utilise pour les classes internes, à savoir SomeFeature$Foo pour une classe nommée et SomeFeature$1 pour une classe anonyme.

Après un exercice intellectuel évolué j'ai conclu que le meilleur usage (en pleine subjectivité) pour une telle classe devait être SomeFeature$ : c'est complètement en phase avec ce qui existe déjà, donc on est certain qu'il n'y aura pas d'interdiction future pour ce caractère.

SomeFeature  // c'est le nom de notre interface
SomeFeature$ // c'est le nom de l'implémentation

J'utilise cette convention (avec moi-même) de nommage dans mon code depuis quelque temps, et je trouve cela plus joli. J'ai baptisé cette règle la notation américaine, je vous laisse deviner pourquoi.

Semantic Mismatch
ERR-19 : IllegalArgumentException
RIDICULE can't have SOMMET
-- In "Le sommet du ridicule"
-- See log for details