The Clean Programmer Manifesto ou Robert Martin's Short Code Book Summary

Cet article est un synopsis du livre Clean Code de Robert Martin et ma compréhension de la façon dont le code propre devrait être. Il n'y a aucune section sur les tests, TDD, quelle architecture devrait être, etc. Ici, tout est à peu près ce que devrait être le Clean Code.

Oui, peut-être que le sujet de Clean Code est déjà galvaudé, mais néanmoins, tout le monde ne le connaît pas et, de plus, je n'ai pas rencontré d'analogues du contenu qui est contenu dans mon article.

Général

Il n'y a pas de véritable voie et solution. Il y en a un qui convient le mieux à une tâche spécifique.

Lors de la résolution d'un problème, essayez de reproduire absolument tous les cas susceptibles d'affecter cette tâche et implémentez la tâche en tenant compte de tous les cas.

Aussi, lors de la résolution du problème, essayez de partir du contraire. Comprenez quel type de résultats vous souhaitez obtenir à la fin et faites sur cette base l'algorithme par lequel la tâche sera effectuée.

Avant d'envoyer une tâche à libérer, vérifiez si elle fonctionne correctement. Y a-t-il des erreurs. Cela s'applique même aux commits envoyés à votre succursale. Le scénario le plus idéal est celui dans lequel personne n'a pu trouver d'erreurs dans la fonctionnalité que vous avez développée.

Réfléchissez toujours à la façon dont vous pouvez rendre votre code plus simple, plus propre et plus lisible.

• Quels cas peut avoir une tâche?
• Ai-je tout pris en compte?
• Qu'est-ce qui pourrait mal tourner?
• Que peut-on combiner?
• Existe-t-il des fonctionnalités similaires?
• Qu'est-ce qui est superflu ici?
• Comment rendre cela plus facile?
• Comment le rendre plus lisible?
• Comment le rendre plus clair?

Code propre

Comment écrire du code propre et bon? C'est comme écrire un livre. D'abord, vous faites un brouillon, puis vous le peignez à l'état dans lequel vous seriez heureux de le lire. N'oubliez pas que votre code doit raconter une histoire pour que le lecteur puisse la comprendre.

Une entité est comprise - une interface, une classe, une méthode, une variable, un objet, etc.

• Le code propre est simple, expressif et axé sur une tâche spécifique.
• Le code propre est facile à lire, comme la prose. Si ce n'est pas le cas, cela vaut la peine d'être refactorisé.
• Le code propre est facile à modifier. Il ne doit pas être lié de manière rigide à un tas d'entités. Toute entité peut être facilement modifiée.
• Le code propre passe beaucoup mieux par un examen. Si l'examen s'accompagne de nombreux commentaires, il n'est pas propre et doit être refactorisé.
• Le code propre a toujours l'air d'avoir été travaillé pendant très longtemps. Quelle que soit la façon dont vous cherchez à l'améliorer, vous arriverez toujours à la conclusion que ce code est le meilleur. En conséquence, un code propre est pensé dans les moindres détails.
• Règle du scoutisme: laissez la place de stationnement plus propre qu'elle ne l'était avant vous. Cela passe facilement à la programmation. Voir le code sale? Rendez-le plus propre pendant que vous résolvez votre problème. Vous ne devriez pas vous laisser emporter par cela, et si le code sale est très sale, vous devez allouer une tâche et un temps distincts pour le nettoyer.
• N'ayez pas peur de faire des changements. Si vous voulez les faire, vous avez des raisons à cela, ce qui signifie que vous rendrez le code meilleur et plus propre. De plus, les tests montreront s'il y a des erreurs dans votre code (à condition qu'elles existent).
• Toute entité devrait être responsable d'une seule fonction et uniquement de celle-ci. Et elle doit bien le faire. Responsabilité unique.
• Si une entité est immédiatement responsable de deux actions ou plus, sa fonctionnalité doit être séparée.
• Le code doit être lu de haut en bas.
• Dans une architecture bonne et compétente, faire des changements sans coûts et efforts importants.
• Supprimer le code mort. Un code mort est un code qui ne sera appelé sous aucune condition ou un code qui n'est utilisé nulle part.

Noms et divisions

• Utilisez des noms clairs et faciles à prononcer pour toutes les entités. Ils devraient décrire pourquoi cette entité existe, ce qu'elle fait et comment elle est utilisée.
• N'ayez pas peur de perdre du temps à choisir le meilleur nom et convivial. Vous gagnerez à l'avenir en travaillant ou en lisant ce code.
• Si le nom de l'entité ne correspond pas à sa fonctionnalité ou si le nom ne comprend pas ce que fait l'entité, alors il doit être renommé en le nom le plus compréhensible. Si cela est impossible, alors quelque chose ne va pas avec son fonctionnement et il doit être refactorisé.
• L'entité, qui porte le nom "Et", "Avec" - viole la responsabilité unique. La fonctionnalité d'une telle entité mérite d'être partagée. Mais cette règle est parfois négligée.
• Les textes incompréhensibles, les lignes doivent être prises en variables et leur donner des noms clairs.
• Les noms de méthode doivent contenir un verbe qui décrit ce que fait cette méthode et le mot-clé avec lequel cette méthode fonctionne. Si le nom de la méthode n'a pas de verbe, alors cette entité ne doit pas être une méthode ou il faut lui donner le nom correct.
• Les mêmes noms doivent être évités pour deux raisons différentes.
• Si une entité a un nom similaire à celui d'une autre entité, alors très probablement, leur fonctionnalité est très similaire et doit-elle être combinée? Sinon, leurs noms doivent être modifiés afin qu'ils ne soient pas similaires.
• Si vous renommez mentalement une entité lorsque vous lisez le code afin de mieux comprendre sa fonctionnalité, renommez-la en ce nom mental.
• Choisissez un mot pour un concept. Il sera difficile de comprendre la fonctionnalité lorsque vous aurez récupéré, récupéré et obtenu les noms. Mieux vaut aller partout.
• Un nom long et compréhensible vaut mieux qu'un nom court mais incompréhensible.

Les fonctions

• Les fonctions doivent être courtes et compactes.
• Les fonctions doivent être très courtes et très compactes.
• Un maximum approximatif de 20 lignes et 150 caractères sur une ligne, si cela ne correspond pas, alors vous devez vous séparer.
• Une fonction ne doit effectuer qu'une seule opération.
  
  • Elle doit bien le faire et elle ne doit rien faire d'autre.
  • Si une fonction effectue uniquement les actions qui sont au même niveau d'abstraction, alors la fonction effectue une opération.
  • Pour déterminer si une fonction effectue plusieurs opérations, essayez d'en extraire une autre, ce qui ne sera pas une simple reformulation de l'implémentation.
• Toutes les instructions conditionnelles avec des choix longs via switch-case, if-else doivent être divisées ou combinées sans duplication, éventuellement dans des classes avec implémentations, et transférer le choix de l'implémentation vers la classe de base, l'usine ou quelqu'un d'autre.
• Si, sinon, pendant, etc. doit contenir un appel à une fonction. Il sera plus lisible, plus clair et plus facile.
• Le nombre idéal d'arguments d'entrée pour une fonction = 0. S'il y a plus de trois arguments d'entrée, alors il vaut la peine de réfléchir à la meilleure façon de s'en débarrasser, par exemple, créez une classe pour ces arguments.
• Plus il y a d'arguments en entrée, plus la fonction est difficile à comprendre.
• La fonction à laquelle l'argument argument est passé, dont dépend le fonctionnement de la fonction, indique que la fonction effectue plusieurs opérations. Ces fonctions doivent être divisées en deux et appelées un niveau supérieur.
• Une fonction qui modifie l'argument d'entrée doit donner une référence à l'objet modifié, et pas seulement le modifier sans retourner. String transform(String text)
• Si la fonction doit changer l'argument d'entrée, laissez-la changer l'état de son objet propriétaire.
• Si l'argument d'entrée de la fonction ne doit pas changer (et est utilisé plus loin dans le code), vous devez copier la valeur de l'argument et travailler avec la copie à l'intérieur de la fonction.
• Au lieu de retourner null, il est préférable d'utiliser un objet vide - Collection.empty() ou un objet null - EmptyObject() .
• Essayez toujours d'utiliser des fonctions non statiques. Si ce n'est pas possible, utilisez statique.
• S'il existe un code qui doit se succéder, passez les résultats de la première fonction à la seconde afin que personne ne modifie la séquence des appels.
• Utilisez le polymorphisme au lieu de if / else ou switch / case ou when.
• Évitez les conditions négatives.

Commentaires

• N'utilisez pas de commentaires si vous pouvez utiliser une fonction ou une variable à la place.
• Ne commentez pas le mauvais code - réécrivez-le. Cela ne vaut pas la peine d'expliquer ce qui se passe dans un mauvais code, il vaut mieux le rendre explicite et compréhensible.
• Les commentaires peuvent être utilisés pour transmettre des informations, des avertissements sur les conséquences, mais pas pour expliquer le fonctionnement du code.
• Utilisez TODO et FIXME dans les cas où vous devez noter que le code doit être amélioré, mais maintenant il n'y a plus de ressources pour cela.
• Utilisez //region REGIONNAME //endregion REGIONNAME , et si vous l'utilisez, réfléchissez s'il est possible de diviser la région en entités.
• Code de document complexe mais propre.
• Ne laissez pas l'ancien code commenté. Vous pouvez le trouver dans l'historique des validations, si nécessaire.
• Les commentaires doivent être concis et clairs. Les commentaires d'information ne devraient pas contenir beaucoup d'informations. Tout doit être bref et précis.

Formatage et règles

• Suivez le codestyle adopté sur le projet.
• Suivez les règles acceptées dans l'équipe.
• Sous réserve de mise en forme et de style de code, le code sera plus facile à lire et meilleur. Ce n'est pas en vain que le livre est remis à l'éditeur avant de le publier.
• Vous devez disposer d'outils automatiques qui formateront le code pour vous.
• Le fichier source doit ressembler à un article de journal. Il y a un en-tête, une brève description sous forme de paramètres et un contenu sous forme de fonctions. Si ce n'est pas le cas, vous devez modifier la mise en forme.
• Les entités liées les unes aux autres doivent être proches, par exemple, dans un seul package, afin de faciliter la navigation dans le code.
• Les variables (champs) de classe doivent être en haut de la classe.
• Les variables de méthode doivent être plus proches de leur lieu d'utilisation.
• Les fonctions doivent être dans l'ordre de l'appel. Si l'un appelle l'autre, la fonction appelante doit être au-dessus de l'appelé. D'un autre côté, les fonctions privées de niveau inférieur peuvent se trouver au bas du fichier et ne pas interférer avec la compréhension du code de haut niveau. Mais je préfère la première façon.

Objets et structures de données

• Vous devez travailler avec des abstractions afin que l'implémentation puisse être facilement modifiée.
• Vous devez travailler avec des abstractions, car le client utilisant la fonctionnalité ne doit pas connaître les détails de l'implémentation, il doit savoir quelle implémentation utiliser dans quel cas.
• Vous devez fournir une API avec laquelle vous devez travailler et masquer les détails de mise en œuvre, la structure. Il sera donc plus facile de travailler avec de telles entités et d'ajouter de nouveaux types de comportements, de fonctionnalités et d'implémentations.
• DTO - Objet de transfert de données. Une classe qui contient uniquement des données et aucune fonctionnalité. Il est nécessaire pour transférer certaines données. Un objet de cette classe doit être immuable.

Cours

• Les cours doivent être compacts.
• Les classes devraient être encore plus compactes.
• Le nom de la classe doit décrire sa responsabilité. De là, vous pouvez calculer la taille de la classe.
• La fonctionnalité de la classe doit correspondre clairement et correspondre au nom de la classe.
• Divisez la connectivité en petites classes. Il ne doit pas y avoir de cohésion rigide et abondante - cela complique le soutien et le développement du projet.
• N'oubliez pas la responsabilité unique. Une entité doit avoir une et une seule raison de changer.
• Observez l'encapsulation. L'encapsulation affaiblie devrait toujours être le dernier recours.
• Habituellement, nous déclarons les variables et les fonctions auxiliaires privées, mais parfois elles doivent être déclarées protégées et pouvoir y accéder depuis le test.
• Si un groupe de fonctions appartient à une certaine fonction, ce groupe de fonctions peut et doit être alloué à une classe distincte et utiliser son instance.

Gestion des erreurs

• Utilisez des exceptions au lieu de renvoyer des codes d'erreur.
• La gestion des erreurs est une opération. S'il y a un mot clé try dans la fonction, alors après les blocs catch/finally , il ne devrait plus y avoir rien d'autre dans la fonction.
• Si vous avez une énumération qui répertorie les erreurs, il est préférable de s'en débarrasser et d'utiliser des exceptions à la place.
• Utilisez des exceptions non vérifiées pour indiquer explicitement l'endroit où il y a des problèmes. Ces erreurs n'ont pas besoin d'être détectées, mais vous devez écrire du code pour que cette erreur n'existe jamais.
• Transmettez suffisamment d'informations et lancez une exception pour que plus tard vos utilisateurs de code puissent comprendre ce qui s'est réellement passé.
• Au lieu d'instructions conditionnelles avec gestion des erreurs, il est préférable de lever des exceptions et de les gérer.
• Ne passez nulle nulle. Essayez d'éviter cela autant que possible.
• La gestion des erreurs est une tâche distincte et ne s'applique pas à la logique principale du programme.

Frontières

• Nous utilisons toujours certaines bibliothèques qui nous donnent le plus souvent des fonctionnalités trop larges, trop petites ou en conflit avec les fonctionnalités attendues, ce qui rend le code plus désordonné dans son utilisation finale. Vous pouvez éviter cela en appliquant simplement des motifs tels que décorateur, adaptateur, façade ou autres.
• Il existe des situations où vous devez travailler avec des fonctionnalités en cours de développement ou qui n'ont pas encore été adaptées pour être utilisées dans le code de production. Dans ce cas, vous devez imaginer ce que vous attendez de la bibliothèque / de cette fonctionnalité et écrire votre interface ou créer une entité avec laquelle vous travaillerez dans votre projet comme vous le souhaitez. Lorsque la bibliothèque est terminée et devient stable, vous l'adaptez à vos structures prêtes à l'emploi et utilisez des fonctionnalités prêtes à l'emploi.

Postface

Cet article fournit uniquement des instructions pour écrire un code propre. Bien sûr, ils peuvent être négligés. Vous avez juste besoin de comprendre que chacune de vos décisions devrait avoir des arguments en sa faveur.