50 mauvais conseils de codage pour développeur C++

Presque tous les articles du C++ fournissent des informations sérieuses et exigent une lecture réfléchie — de préférence avec une tasse de café. Et parfois, on veut juste s'amuser. C'est pourquoi j'ai décidé d'écrire cet article humoristique avec des mauvais conseils de codage. Il est très important de ne pas confondre ces conseils avec des conseils utiles !

J'écris des articles sur la méthodologie de l'analyse statique et sur les problèmes de création de code de bonne qualité. Mais, j'avais envie de m'amuser un peu. Alors, s'il vous plaît, accueillez l'article avec 50 mauvais conseils de codage. Si vous avez d'autres idées pour créer sh*tcode, n'hésitez pas à partager vos commentaires. Il est possible que je publie un nouvel article contenant 100 mauvais conseils de codage :).

Si vous ne comprenez pas pourquoi le conseil est appelé mauvais, cliquez sur le {lien}. S'il n'y a pas de lien, dites-le-moi. Je vais partager une explication plus détaillée.

• Un vrai programmeur ne programme qu'en C++ ! {1}
• Si vous avez besoin d'un caractère tab dans un littéral de string, n'hésitez pas à appuyer sur la touche Tab. Laissez \t aux autres. Ne vous inquiétez pas.
• Utilisez des nested macros partout. C'est un bon moyen de réduire le code. Vous libérerez de l'espace sur le disque dur. Vos coéquipiers s'amuseront beaucoup lors du débogage. {3}
• Désactivez les warnings du compilateur. Ils vous détournent de votre travail et vous empêchent d'écrire un code compact.
• Utilisez une ou deux lettres pour nommer les variables. De cette façon, vous pourrez faire tenir une expression plus complexe sur une ligne de l'écran.
• Utilisez des nombres en programmation. De cette façon, le code de votre programme sera plus intelligent et plus impressionnant. Voici un exemple de ligne de code : qw = ty / 65 - 29 * s;. C'est hardcore, non ? {6}
• Utiliser les caractères invisibles dans votre code. Laissez votre code fonctionner comme par magie. C'est cool, non ?
• Tous les anciens livres recommandent d'utiliser des variables de int type pour stocker array sizes et pour construire des loops. Continuons comme ça ! Ne rompez pas la tradition. {8}
• Les variables globales sont exceptionnellement pratiques car vous pouvez y accéder de n'importe où.
• Le conseil pour les développeurs de bibliothèques : en cas de doute, terminez immédiatement le programme avec la fonction abort ou terminate. {10}
• Si quelque chose ne fonctionne pas, c'est probablement le compilateur qui fait des siennes. Essayez d'échanger quelques variables et lignes de code. {11}
• Il n'y a pas le temps d'expliquer — utilisez immédiatement les arguments de la ligne de commande. Par exemple : char buf[100]; strcpy(buf, argv[1]);. Les vérifications sont pour ceux qui ne se sentent pas trop confiants quant à leurs propres compétences en codage ou les compétences de leurs coéquipiers. {12}
• Un comportement indéfini est une histoire effrayante à dormir debout. Un comportement indéfini n'existe pas dans la vraie vie. Si le programme fonctionne comme prévu, il ne contient pas de bugs. Et il n'y a rien à discuter ici, c'est tout. {13}
• N'hésitez pas à utiliser l'opérateur == pour comparer des nombres à virgule flottante. Si un tel opérateur existe, vous devez l'utiliser. {14}
• memmove est une fonction superflue. Utilisez memcpy toujours et partout. {15}
• La taille du pointeur et la taille de l'int sont toujours de 4 bytes. N'hésitez pas à utiliser ce numéro. Le nombre 4 semble beaucoup plus élégant qu'une expression maladroite avec l'opérateur sizeof. {16}
• Cela n'a aucun sens de vérifier si la mémoire a été allouée. Les ordinateurs modernes ont une grande quantité de mémoire. Et s'il n'y a pas assez de mémoire pour terminer les opérations, le programme n'a pas besoin de continuer à fonctionner. Laissez le programme se plante. Il n'y a rien de plus à faire de toute façon. {17}
• Étendez l'espace de noms (namespace) std avec diverses fonctions et classes supplémentaires. Après tout, pour vous, ces fonctions et classes sont standard et basiques. Et si c'est le cas, l'espace de nom std est celui auquel ils appartiennent. {18}
• Vos coéquipiers doivent connaître votre vaste expérience du langage C. N'hésitez pas à leur montrer vos compétences en gestion manuelle de la mémoire et en utilisation de longjmp.
• Utilisez le moins possible de accolades et de line breaks. Essayez d'écrire les constructions conditionnelles en une seule ligne. Cela permettra de réduire la taille du code et de le compiler plus rapidement. {20}
• Ne jamais rien tester. Et n'écris pas de tests. Votre code est parfait, qu'y a-t-il à tester ? Ce n'est pas pour rien que vous êtes de vrais programmeurs C++. {21}
• Et n'utilisez pas d'analyseurs statiques. Ce sont des outils pour les étudiants et les perdants. {22}
• Déployez toujours et partout toute modification immédiatement en production. Les serveurs de test sont un gaspillage d'argent.
• Utilisez toujours autant d'objets imbriqués (nested objects) que possible. Le code complexe semble digne de confiance !
• N'utilisez jamais de composants sous licence. N'utilisez que des produits pirates. Où les trouver ? Sur les sites web suspects. Pourquoi devez-vous payer d'autres programmeurs ? Surtout s'ils n'utilisaient soudainement pas C++. Beurk.
• N'utilisez pas la bibliothèque standard de langues. Quoi de plus intéressant que d'écrire ses propres strings et listes avec une syntaxe et une sémantique unique ? {26}
• N'utilisez pas des pointeurs intelligents (smart pointers) et RAII. Toutes les ressources doivent être gérées manuellement, ce qui rend le code simple et compréhensible.
• En général, l'allocation de mémoire est diabolique. char c[256] est suffisant pour tout le monde, et si ce n'est pas suffisant, nous le changerons en 512. À tout le moins — en 1024.
• N'utilisez pas des systèmes de versionnage. Stockez les sources directement sur le serveur de la machine virtuelle.
• L'alignement et le style de code ne permettent pas d'exprimer votre individualité et votre créativité. C'est une violation de la liberté personnelle et de l'expression de soi. Chacun devrait écrire du code comme il le souhaite.
• Utilisez plus de code dans les fichiers d'en-tête (header files). C'est beaucoup plus pratique, et le temps de compilation n'augmente que légèrement. {31}
• On dit que goto est nuisible. C'est absurde ! L'instruction goto est exceptionnellement puissant et peut remplacer de nombreuses autres instructions. Longue vie à goto et l'ascèse !
• N'utilisez jamais d'enums, ils se transforment implicitement en int de toute façon. Utiliser int directement ! {33}
• Utilisez autant de build systems et de gestionnaires de paquets différents que possible. Montrez à tous que vous êtes au courant des tendances modernes ! Bien sûr, les versions du code dans les paquets pour les différents gestionnaires devraient être légèrement différentes. Sinon, les utilisateurs se lasseront.
• Montrez un peu de respect pour les programmeurs du passé — déclarez toutes les variables au début des fonctions. C'est la tradition ! {35}
• Incluez autant de fichiers d'en-tête que possible afin que chaque fichier .cpp s'ouvre en un million de lignes — vos coéquipiers vous remercieront d'avoir plus de temps pour une pause cigarette pendant le rebuild ! {36}
• Écrivez vos fichiers .h de manière à ce qu'ils dépendent d'autres headers, et ne les incluez pas dans votre fichier d'en-tête. Laissez celui qui utilise include deviner quels fichiers d'en-tête doivent être inclus à l'avance avant d'utiliser votre fichier. Divertissez vos collègues avec des quêtes !
• Pourquoi avons-nous besoin de tous ces *_casts s'il existe un reinterpret_cast qui fonctionne toujours ? Et le bon vieux cast comme en C — (Type)(expr) — est encore meilleur et plus court.
• Si vous décidez d'écrire une fonction, elle doit être omnipotente et polyvalente comme un couteau suisse. La fonction devrait prendre beaucoup d'arguments. Pour gagner du temps, vous ne pouvez pas énumérer les arguments, mais les analyser en utilisant va_arg.
• Qu'y a-t-il de mal à regarder une variable voisine à travers un pointeur vers une variable ? C'est-à-dire, nous sommes dans les limites de notre mémoire. {40}
• Le const word prend juste de la place dans le code. Si vous ne voulez pas changer une variable, vous pouvez la laisser comme ça. {41}
• Saviez-vous qu'au lieu des accolades, vous pouvez utiliser <% et %> ? Les digraphes et trigraphes peuvent rendre votre code vintage et unique. Votre code se démarquera du code de vos coéquipiers. Vous ne faites rien d'illégal. Les digraphes et les trigraphes sont dans le standard.
• Pourquoi initialiser des variables s'il y a déjà des nuls ? C'est-à-dire, juste l'autre jour, je n'ai pas initialisé les variables et il y avait null. Tout a fonctionné.
• private est pour ceux qui ne se sentent pas en confiance. Quoi qu'il en soit, qui a besoin de ces class fields ?
• Créez des variables avec les mêmes noms mais des numéros différents : index1, index2. Autant que possible. {45}
• Écrivez votre code comme si le président des juges de l'IOCCC le lirait et comme s'il/elle savait où vous habitez (pour venir te remettre le prix). {46}
• Si line breaks et indents sont insignifiants en C++, pourquoi ne pas écrire le code sous la forme d'un lapin ou d'un écureuil ?
• Tout le monde sait que l'opérateur [ ] est commutatif. Alors ne sois pas comme tout le monde. Donnez de l'originalité au code en utilisant les 1 [tableau] = 0 constructions.
• Pour autant de types que possible, surchargez autant d'opérateurs que possible, y compris les opérateurs non arithmétiques. En donnant aux opérateurs un sens différent, vous vous rapprochez de la création de votre langue dialecte. La création de votre langue est amusante. Et si vous ajoutez également des macros...
• La classe std::string universel est inefficace. realloc, strlen, strncat fonctionnent plus rapidement et efficacement. {50}
• Si vous pouvez vous référer à l'élément past-the-end suivant, cela signifie qu'il est également possible d'accéder à cet élément. Opps, c'est le 51ème élément de la liste, et j'ai promis 50. Désolé, mais quel article C++ sans une erreur de type off-by-one :). {51}

Ces conseils vous rappelleront probablement l'un de vos collègues :) Alors, il est temps de partager cet article avec eux. Au revoir ! Rendez-vous dans le débogueur !