Quel est le problème avec la dénomination ? Et pourquoi devrions-nous même nous en soucier ? C'est juste un nom.
La dénomination des variables, des méthodes, des classes, des packages, etc. reçoit souvent moins d'attention qu'elle ne le mérite. Il arrive très souvent que nous rencontrions des noms comme i,j,k ou des noms dénués de sens comme customerServicingProfileObjectUtil. Nous ne pensons pas qu’il soit important de prendre quelques minutes pour trouver de meilleurs noms pour les composants de notre programme. Après tout, ce n'est qu'un nom. Si nous ne comprenons pas ce qu’il fait, nous pouvons toujours simplement lire le code et le comprendre.
Nommer peut signifier plus que nous ne le pensons. Si nous ne parvenons pas à trouver un bon nom pour un composant, cela pourrait signifier l'un des éléments suivants
- Nous ne comprenons pas les responsabilités de ce composant
- Il a plus d'une responsabilité
Ainsi, en trouvant un bon nom, nous pouvons voir clairement les problèmes et refactoriser le code pour mieux le nettoyer. Cela contribue également à la lisibilité de notre code. Si nous voyons une méthode avec un nom révélateur d’intention, nous n’avons pas besoin de fouiller dans cette méthode pour essayer de comprendre ce qu’elle fait, ce qui accélère la compréhension du code. Après tout, nous écrivons le code de manière à le faire comprendre aux autres humains.
Une autre odeur de mauvais code est lorsque nous devons utiliser des commentaires pour décrire un composant au lieu d'utiliser son nom. Au lieu de cela, nous pouvons simplement renommer le composant avec un nom significatif afin d'éviter d'avoir besoin de ce commentaire.
Exemple de Robert C Marting dans son livre de codes Clean :
Au lieu de int d; // elapsed time in days, utilisez int elapsedTimeInDays
Lorsque nous nommons correctement les composants, nous les comprenons mieux et nous réalisons qu’ils peuvent appartenir à des endroits différents. Fondamentalement, nous refactorisons mieux le code.
