Les gens, de par leur nature, sont enclins à commettre des erreurs. Cependant, de nombreuses lacunes spécifiques aux développeurs peuvent être évitées. Si un programmeur est capable de se débarrasser des erreurs courantes qui seront discutées dans cet article, il pourra écrire un code meilleur et plus propre.
L'élimination des failles dans le code profitera non seulement à ceux qui s'en débarrasseront, mais aussi aux programmeurs qui doivent lire ce code. En conséquence, nous pouvons dire que ceux qui travaillent en équipe et s'efforcent d'améliorer leur code le font non seulement pour eux-mêmes, mais aussi pour ceux avec qui ils travaillent.
Voici quelques défauts courants qu'un programmeur devrait éviter.
1. Trop d'actions dans la fonction
Conformément au principe de la responsabilité exclusive, une fonction ne devrait être responsable que de l'exécution d'une seule opération. Et cela ne devrait être qu'une opération. J'ai vu trop de fonctions qui effectuent le chargement, le traitement et la présentation de certaines données. On pense que la mise en œuvre de telles actions est mieux répartie entre plusieurs fonctions. Une fonction charge des données, une autre traite, la troisième est responsable de leur présentation.
La raison de l'importance d'écrire des fonctions qui se concentrent sur la résolution d'un seul problème est que cette approche rend le code plus fiable. Supposons que dans le cas ci-dessus, les données soient chargées à partir d'une certaine API. Si cette API change, par exemple, si une nouvelle version est publiée, il est fort probable que la fonction entière cesse de fonctionner. Le code qui charge les données chargera quelque chose de mal, cela affectera le traitement et la présentation des données. Pour résoudre le problème, vous devrez d'abord le trouver, découvrir ce qui a échoué, puis modifier le code d'une grande fonction. Si le chargement, le traitement et la présentation des données sont divisés en plusieurs fonctions, il sera beaucoup plus facile de résoudre de tels problèmes.
2. Le projet a commenté le code
Tout le monde a vu le code, dont de gros fragments, par exemple, contenant certaines fonctions, sont commentés. Cependant, personne ne sait pourquoi ces fragments ne sont toujours pas supprimés de la base de code. Et personne ne sait si ces morceaux de code fonctionneront s'ils ne sont pas commentés. Mais en même temps, ils ne sont pas supprimés. Et vous devez les supprimer. La raison pour laquelle ce code pollue les projets est que tout le monde suggère que quelqu'un pourrait avoir besoin de ce code.
Ces fragments de code doivent être simplement supprimés. Et si dans la dernière version du code ces fragments distants ne sont pas présents, et en même temps que quelqu'un en a vraiment besoin, ils peuvent être trouvés dans le système de contrôle de version. Je note que ce n'est que mon avis sur cette question.
3. Mauvais noms de variables
Une fois, j'ai écrit
un article qui présentait des règles simples pour sélectionner de bons noms de variables. Les noms de variables qualitatives sont extrêmement importants. Le fait est que les programmeurs ne travaillent généralement pas seuls sur des projets. Leurs collègues doivent comprendre le code qu'ils écrivent. Les noms de variables conviviaux aident à améliorer la perception du code de quelqu'un d'autre.
Je répète ce que j'ai dit dans le document ci-dessus: "Choisir de bons noms de variables prend du temps, mais cela fait gagner plus de temps qu'il n'en faut."
4. «Chiffres magiques» et cordes
Si nous continuons nos discussions sur le problème des noms de variables obscurs, nous pouvons arriver à l'idée d'utiliser certaines valeurs dans le programme, des «nombres magiques» ou des chaînes qui n'ont aucun nom et qui ne sont écrites dans aucune variable.
Vous pouvez apprendre de
Wikipédia que les «nombres magiques» sont appelés mauvaises pratiques de programmation lorsqu'une valeur numérique est trouvée dans le texte source et que sa signification n'est pas évidente.
Jetez un œil à l'exemple de code suivant:
for ($i = 1; $i <= 52; $i++) { ... }
Ici, la valeur
52 est le «nombre magique». Personne ne sait pourquoi c'est exactement le nombre 52 et ce que cela signifie. Pourquoi 52? Pourquoi pas 64? C'est peut-être le nombre de semaines dans une année?
Ce code deviendra beaucoup plus clair si vous le réécrivez comme ceci:
$cardDeckSize = 52; for ($i = 1; $i <= $cardDeckSize; $i++) { ... }
Maintenant, tout le monde comprendra que dans un cycle, nous passons par un jeu de cartes. Cela indique aux autres développeurs l'essence de ce qui se passe, aide à comprendre le contexte de l'action en cours. De plus, cette approche simplifie considérablement le changement de cette valeur, car si elle est utilisée à différents endroits du programme, elle n'est définie qu'à un seul endroit dans le code.
La même chose s'applique au travail avec des chaînes:
if (userPasswordIsValid($user, "6yP4cZ".$password)) { ... }
Qu'est-ce
6yP4cZ ce
6yP4cZ ? Ressemble à un jeu de caractères aléatoire.
Nous réécrivons ceci:
$salt = "6yP4cZ"; if (userPasswordIsValid($user, $salt.$password)) { ... }
Mais maintenant, tout est beaucoup plus clair.
5. Formatage de code inexact
Le formatage de code désordonné est une "maladie" pour les programmeurs débutants. De nombreux développeurs ayant une certaine expérience ont tendance à hocher la tête affirmativement lorsqu'on leur demande s'ils connaissent un testeur ou un data scientist qui ne formate pas bien le code. La raison en est un manque d'expérience. Les seules exceptions sont les programmeurs qui utilisent un langage comme Python, dans lequel la mise en forme du code affecte l'exécution du programme.
L'une des façons les plus courantes de résoudre ce problème consiste à utiliser un linter. De plus, tous les IDE modernes prennent en charge la possibilité de formater automatiquement le code. Parfois, cette fonctionnalité est implémentée au moyen de plugins que vous devez installer vous-même, et parfois elle est incluse dans les fonctionnalités IDE standard.
6. Valeurs codées en dur dans le code
Si les valeurs sont codées en dur dans des programmes, cela signifie que les données sont intégrées directement dans le code source ou dans d'autres objets similaires. L'opposé de cette approche consiste à obtenir des données à partir de sources externes ou à les générer lors de l'exécution du programme.
Les valeurs fixes ne permettent pas une configuration facile du programme. Ils sont pour ainsi dire «sculptés dans la pierre». Ceci est considéré comme un anti-modèle ou, au minimum, indique des problèmes évidents dans le code.
Le plus souvent, les mots de passe et les chemins d'accès aux fichiers sont codés en dur. Ils le font pour diverses raisons, parfois ils peuvent même être justifiés.
Par exemple, de nombreuses valeurs codées en dur peuvent être vues dans certains exemples de code responsable de l'authentification sur des services externes ou des API. Il vaut mieux ne pas faire ça.
Si quelqu'un a remarqué l'utilisation fréquente de valeurs codées en dur, il doit évaluer de manière critique son travail. Le fait est que l'utilisation de telles valeurs n'est généralement pas la meilleure façon de résoudre certains problèmes.
Chers lecteurs! Quelles lacunes du code avez-vous rencontrées?
