Écrire un code fonctionnel n'est jamais suffisant. Vous devez l'écrire d'une manière maintenable et compréhensible. À cette fin, Robert Cecil Martin a défini à quoi ressemblerait un code propre. Dans cet article, j'expliquerai les points les plus importants de l'écriture de code propre.

Un code propre est un code efficace, simple, lisible et sans doublons. Vous devez suivre ces instructions, car il est plus facile d'écrire votre code propre en premier lieu que de nettoyer du code mal écrit.

Noms significatifs

• Les noms des classes, des méthodes et des variables doivent être nommés de manière significative et claire, démontrant ce qu'ils sont censés faire
• Votre nom doit être prononçable pour faciliter la communication entre les développeurs.
• Évitez les acronymes ou les noms ambigus, qui confondent ceux qui lisent votre code.
• Utilisez des noms qui représentent le domaine du système, le contexte et les problèmes à résoudre.
• Utilisez des mots conceptuels de manière cohérente. Si, par exemple, vous utilisez le mot « récupérer », n'utilisez pas de mots comme « récupérer » ou « obtenir ». Tenez-vous en à votre convention.
• Essayez de ne pas utiliser le même mot à deux fins

• Les méthodes doivent être lisibles et compréhensibles.
• Les blocs tels que les instructions "if et else" et les instructions "while" doivent être longs d'une ligne.
• La méthode doit transmettre son intention.
• En lisant la fonction de haut en bas, les lecteurs devraient être en mesure de comprendre ce que vous essayez d'accomplir. Les lignes consécutives doivent être relatables. De plus, le niveau d'abstraction devrait être diminué de haut en bas.
• Les méthodes doivent être petites et doivent comporter jusqu'à 20 lignes.
• Chaque méthode doit faire une chose.
• Les méthodes doivent véhiculer le travail que son nom suggère.
• Le nombre optimal de paramètres d'une méthode est zéro, après un et deux. Sauf si vous avez une bonne raison, n'utilisez pas le troisième paramètre.
• Évitez les effets secondaires, ce qui signifie que vos méthodes ne doivent rien changer qui ne soit pas impliqué par le nom de la méthode
• Essayez d'éviter d'utiliser des arguments de sortie sur des abstractions de haut niveau.
• Les méthodes doivent soit répondre à quelque chose, soit faire quelque chose, mais pas les deux.
• Évitez les doublons. Mettez des blocs de code répétés dans des méthodes.

• L'utilisation de commentaires est un signe que le code que vous avez écrit n'est pas assez clair.
• Aucun commentaire ne peut sauver du code mal écrit.
• Au lieu d'expliquer ce que fait une méthode, donnez un nom approprié qui indique ce que la méthode est censée faire. La même chose s'applique aux noms de variables.
• Les points importants du code peuvent être exprimés par des commentaires.
• Les commentaires ne doivent pas être utilisés pour indiquer qui a modifié le code ou pourquoi. Le contrôle de version le fait déjà.
• Évitez de commenter le code qui ne sera pas utilisé, car cela entraînera des odeurs de code. Supprimez simplement ce genre de commentaires.

• N'écrivez pas le code à la manière d'un spaghetti. C'est difficile à lire.
• Les classes ne doivent pas dépasser 500 lignes. Les petites classes peuvent être comprises facilement.
• Gardez une bonne limite de caractères -environ 120- par ligne de code.
• Créez un flux de code en conservant consécutivement les lignes de code associées.
• Utilisez des espaces entre les paramètres, les opérateurs et les virgules.

• Utilisez des abstractions de données pour exposer des interfaces qui permettent aux développeurs de manipuler les données, sans connaître leur implémentation.
• Les structures de données forment une interface pour manipuler les données. Ils ne nécessitent pas de méthodes importantes.

• Enregistrez les erreurs avec les informations sur les causes. Mentionnez l'endroit où l'erreur s'est produite et pourquoi elle s'est produite.
• Ne retournez pas null dans les méthodes ; renvoie des objets vides.
• Ne transmettez pas de paramètres nuls aux méthodes ; ils provoqueront des NullPointerExceptions.

Suivez la PREMIÈRE règle pour les tests

Le test devrait être;

• vite
• indépendant
• répétable
• auto-validation
• opportun

En Java, les variables doivent être au sommet des classes. L'ordre des différents types de variables est le suivant :

i) variables constantes statiques publiques

ii) variables statiques privées

iii) instances privées de variables.

• Après les variables, les classes doivent continuer avec les méthodes.
• Le nom de la classe doit indiquer son objectif.
• Chaque classe devrait avoir une responsabilité.