Un mauvais code merdique, tu l'aimes ?

Il existe un projet sur GitHub qui décrit dix-neuf principes clés du « meilleur code poubelle ». De la dénomination des variables à la rédaction des commentaires. Ces directives vous guideront dans la rédaction du meilleur mauvais code possible.

Afin de conserver le même style que le projet GitHub original, il n'y a pas de conversion ci-dessous. Les lecteurs peuvent comprendre tous les points de vue du point de vue opposé, ce qui est un moyen idéal pour éviter d'écrire du code inutile.

Adresse du projet :
https://github.com/trekhleb/state-of-the-art-shitcode

Bien sûr, les dix-neuf directives d'écriture de code poubelle suivantes ne sont pas exhaustives si les lecteurs y trouvent. êtes Vous pouvez également exprimer votre opinion sur certaines mauvaises habitudes de codage insupportables.

? Article 1 : Moins il y a de frappe, mieux c'est

Si nous tapons moins, nous avons plus de temps pour réfléchir à la logique du code et à d'autres problèmes. Comme indiqué ci-dessous, « Bon » indique des exemples qui suivent la règle et « Mauvais » indique des exemples qui ne suivent pas la règle.

Article 2 : Style de dénomination mixte des variables/fonctions

Nous devons mélanger les méthodes de dénomination et les variables pour refléter la diversité des dénominations.

 ? Article 3 : N'écrivez pas de commentaires

Vous pouvez quand même comprendre le code, pourquoi devriez-vous écrire des commentaires ? En d’autres termes, personne ne lit mon code de toute façon, alors pourquoi devrais-je écrire des commentaires ?

 ? Règle 4 : Écrivez des commentaires dans votre langue maternelle

Si vous enfreignez la règle 3, écrivez au moins des commentaires dans votre langue maternelle ou dans une autre langue. Si vous êtes de langue maternelle anglaise, vous enfreignez également cette règle. Puisque la plupart des langages de programmation​​sont en anglais, pourquoi ne pas utiliser d’autres langages​​pour commenter ?

Article 5 : Mélanger au maximum différents formats

Encore une fois, pour la diversité du code, nous devons mélanger autant que possible différents formats, tels que des guillemets simples ou doubles. S'ils ont la même sémantique, ils doivent être mélangés.

 ? Article 6 : Écrivez le code sur une seule ligne autant que possible

Si une série de paramètres et de méthodes sont implémentées ensemble, alors le code doit également être écrit ensemble.

?Article 7 : Gardez le silence lorsque vous trouvez des erreurs

Lorsque vous trouvez des erreurs, les autres n'ont pas besoin de le savoir, il n'est donc pas nécessaire d'imprimer le journal ou Retraçage.

?Article 8 : Utiliser largement les variables globales

L'utilisation de variables globales est un élément indispensable pour faire face à la « mondialisation ».

 ? Point 9 : Construire des variables de sauvegarde

Juste au cas où, nous devrions créer des variables de sauvegarde et les appeler à tout moment en cas de besoin.

?Article 10 : Le type doit être utilisé avec prudence

Généralement, ne spécifiez pas de types de variables et n'effectuez pas de vérification de type fréquemment, aucun type n'est le meilleur type.

 ? Article 11 : Préparez le "Plan B"

Vous devez préparer un code inaccessible (code inaccessible), qui peut être utilisé comme votre "Plan B".

?Article 12 : Règle du triangle imbriqué

Si le code comporte des structures imbriquées, ou des structures avec des lignes vides en retrait, la règle du triangle est la plus belle.

 ? Article 13 : Indentation mixte

Nous devons éviter d'utiliser l'indentation, car l'indentation fera prendre plus de place au code complexe dans l'éditeur. Si vous devez utiliser l'indentation, utilisez une stratégie d'indentation mixte. Bien entendu, cette stratégie ne fonctionne pas en Python, qui s'appuie sur l'indentation pour structurer son code.

?Article 14 : Ne verrouillez pas les dépendances

Chaque fois que vous souhaitez installer une nouvelle bibliothèque, mettez à jour les dépendances existantes. Pourquoi conserver la version précédente ? Nous devons à tout moment conserver la dernière base de code tiers.

?Article 15 : Les fonctions longues valent mieux que les fonctions courtes

Ne divisez pas la logique globale du programme en quelques blocs de code Si l'IDE échoue soudainement, il ne peut pas trouver les fichiers nécessaires. ou fonctions. Par conséquent, écrire le code dans une fonction principale et ne plus conserver les importations de fonctions supplémentaires ou les fichiers de code est la méthode la plus stable.

Un seul fichier avec 10 000 lignes de code ne pose aucun problème, et une seule fonction avec mille lignes de code ne pose aucun problème.

?Article 16 : Le code ne nécessite pas de tests spécifiques

Ces tests sont généralement un travail répétitif et dénué de sens.

? Article 17 : Essayez d'éviter de dupliquer du code

Écrivez du code selon vos idées, surtout dans une petite équipe, après tout, c'est le principe de la "liberté".

?Article 18 : Aucun document README n'est requis pour construire un nouveau projet

Au début du projet, nous pouvons continuer ainsi pour le moment.

?Article 19 : Enregistrer le code inutile

Dans le processus d'écriture de code, de nombreux codes de test sont souvent générés. Ces codes sont également des informations très importantes, ils ne peuvent donc pas être supprimés et peuvent uniquement être commentés au maximum.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!