Comment écrire du code non maintenable

25 conseils pratiques pour écrire du code aussi impossible que possible

Dans ce didacticiel, je veux illustrer comment écrire du code non maintenable.

En écrivant du code non maintenable, vous pouvez vous assurertu ne seras jamais virécar tu seras le seul capable de comprendreQuelle code le fait, et surtoutPourquoi.

Remarque: ce post est ironique

  1. Attribuez des noms étranges, fantaisistes et occasionnels à vos variables, fonctions et objets. Il ne devrait y avoir aucune corrélation entre le nom et ce que fait l'élément ou comment il se comporte.
  2. Préférez les abréviations et les acronymes aux noms descriptifs. Les variables à une lettre sont excellentes.
  3. Favorisez la réutilisation des variables dans le code. Toujours utiliseridans vos boucles.
  4. Utilisez votre propre langue pour les noms. Après tout, il n'est pas nécessaire d'utiliser tous l'anglais.
  5. Il en va de même pour les commentaires. N'hésitez pas à les écrire dans la langue que vous parlez, peu importe si le prochain développeur vient d'un autre pays?
  6. Quant aux commentaires, je plaisantais. N'écrivez aucun commentaire.
  7. Si vous voulez vraiment écrire des commentaires, ne vous souciez pas de les mettre à jour lorsque vous modifiez le code qu'ils décrivent.
  8. Préférez les variables globales plutôt que d'être trop intelligent avec la portée
  9. Ne testez jamais votre code. Vous êtes bon, votre code est bon aussi.
  10. Préférez trop compliquer plutôt que d'être trop simpliste. Personne n'a jamais été renvoyé pour avoir créé une architecture complexe et épanouissante qui nécessitait une réécriture inutile de code de 3 mois qui fonctionnait parfaitement.
  11. Optimisez tout ce que vous pouvez de manière intelligente. Les ordinateurs sont lents, il faut éviter de les surchauffer et contribuer à lutter contre le changement climatique. Réécrire votre code en assembly est souvent une bonne idée.
  12. Les langages et les frameworks relativement inconnus sont toujours meilleurs que les solutions populaires et testées au combat. Préférez-les à la solution que tout le monde utilise.
  13. Mieux encore, créez votre propre cadre.
  14. N'utilisez jamais de bibliothèques tierces
  15. Surutilisation des bibliothèques tierces
  16. Utilisez tous les modèles de conception que vous lisez et essayez de les intégrer à votre conception même si ce n'est pas vraiment le cas.
  17. Utilisez des outils conçus par de grandes entreprises, car elles le savent mieux et votre start-up à 1 personne bénéficiera sûrement des milliers d'heures de travail consacrées à leur construction. Des points bonus s'ils sont très compliqués à utiliser et s'ils ont leur propre ensemble de conventions de dénomination intelligentes.
  18. N'utilisez pas le contrôle de version et ne versez même pas du tout le code. Après tout, il n'y a qu'une seule bonne version du programme. Vous pouvez facilement vous souvenir de tous les changements que vous effectuez et surtoutPourquoiun changement a été fait. Pas besoin de le suivre dans un référentiel externe.
  19. Copiez et collez librement le code de Stack Overflow ou de blogs aléatoires sans le comprendre au préalable
  20. L'indentation n'a pas d'importance. Du tout. Mélangez également les espaces et les tabulations.
  21. Abstraction libre des abstractions. Les abstractions sont géniales. Rendez tout réutilisable et réfléchissez trop aux choses comme un roi.
  22. Peut-être que vous réutiliserez cette bibliothèque dans chaque projet que vous réaliserez au cours des 20 prochaines années, qui sait? Mieux vaut penser d'abord à tous les cas de bord possibles.
  23. Mettez toujours en œuvre chaque bonne idée que vous avez
  24. 2000-lines functions are a great idea
  25. Supposons qu'un ingénieur 10x vous surveille pendant que vous codez.

Plus de tutoriels de laboratoire: