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.
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.
pourquoi pas, mais en vrais la taille de variables, doit être proportionnel à la taille de la fonction qui la contiens.
s'amuser à déclarer des variables avec des noms bien explicite, dans une fonction avec un nom déjà bien explicite, ou les paramètres d'entrés on déjà des noms bien explicite, et qui fait 5 lignes de codes, c'est juste rajouter du bruit à ça fonction pour rien. C est un langage spartiate
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.
vrais sujet à débats, mais certain dev LLVM t'expliqueront que laisser un int, vu que c'est moins définit qu'un size_t, ça aide le compilo à optimiser ton programme.
Les variables globales sont exceptionnellement pratiques car vous pouvez y accéder de n'importe où.
oui. mais c'est vrais que quand on fait de l'object bien propre on est tellement au dessus de ça qu'on fait: soit des singleton,
soit on se balade dans la moitié de son code avec le même objet de configuration.
Au final, on à rajouté plein de boilerplate(pas la trad ?), et de code ultra verbeux qui ne serve qu'à éviter les horrible globale, qu'importe si on passer plus de temps a écrire chaque fonctions de son programme pour éviter des problème qui n'arrive pratiquement jamais(en tout SDL et linux s'en sorte très bien avec leur global), c'est plus propre on vous dit !
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
ouais, puis c'est pas comme si tout les OS moderne alloue la mémoire quand ils reçoivent un page-fault, ce qui rend impossible de détecter les erreurs de malloc, et donc rendes en pratique les vérification de la mémoire inutile sur ces OS.
quand on fait du code pour botos sur mars, on est sur de l'embarqué, donc les checks de malloc sont utile, le code pour rover martien, c'est la norme !
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 !
j'ai toujours admirer cette haine du goto, venant de personne qui n'ont jamais lut Dijkstra.
Dijkstra parle d'une utilisation du goto, qui remplacerais les if/else, switch/case, et autre boucles.
Aujourd'hui les utilisation principal de goto, c'est soit les goto-chain.
soit un utilisation avec des pointeur sur label pour optimiser des interpréter, soit pour des retry. mais continuons à répandre la rumeur que les goto sont héréditairement mauvais pour pas utiliser ces technique, que aucun projets sérieux ne prendrais.
ne faisons aucune exception. les try catch sont tellement moins spaghetti.
bon ça fait pas 50 raisons, mais j'ai pu donner tout mes mauvaises opinions de dev, et ca fait plaisir à étaler.
# tout lu mais
Posté par uso (site web personnel) . En réponse au journal 50 mauvais conseils de codage pour développeur C++. Évalué à 4. Dernière modification le 22 février 2023 à 00:16.
je croie qu'il faudrait renommer l'article en:
"50 raison pour laquelle si Coder en C ne servirait qu'a éloigner les dev C++, C resterait un meilleur langage que C++"
Oui, les, macros c'est le mal. les macro c'est bugué. en attendant, un
json_object_object_foreach reste bien plus intuitive a utiliser, et moins verbeux que la plupart des solutions a base d'iterator.
pourquoi pas, mais en vrais la taille de variables, doit être proportionnel à la taille de la fonction qui la contiens.
s'amuser à déclarer des variables avec des noms bien explicite, dans une fonction avec un nom déjà bien explicite, ou les paramètres d'entrés on déjà des noms bien explicite, et qui fait 5 lignes de codes, c'est juste rajouter du bruit à ça fonction pour rien.
C est un langage spartiate
vrais sujet à débats, mais certain dev LLVM t'expliqueront que laisser un int, vu que c'est moins définit qu'un size_t, ça aide le compilo à optimiser ton programme.
oui. mais c'est vrais que quand on fait de l'object bien propre on est tellement au dessus de ça qu'on fait: soit des singleton,
soit on se balade dans la moitié de son code avec le même objet de configuration.
Au final, on à rajouté plein de boilerplate(pas la trad ?), et de code ultra verbeux qui ne serve qu'à éviter les horrible globale, qu'importe si on passer plus de temps a écrire chaque fonctions de son programme pour éviter des problème qui n'arrive pratiquement jamais(en tout SDL et linux s'en sorte très bien avec leur global), c'est plus propre on vous dit !
ouais, puis c'est pas comme si tout les OS moderne alloue la mémoire quand ils reçoivent un page-fault, ce qui rend impossible de détecter les erreurs de malloc, et donc rendes en pratique les vérification de la mémoire inutile sur ces OS.
quand on fait du code pour botos sur mars, on est sur de l'embarqué, donc les checks de malloc sont utile, le code pour rover martien, c'est la norme !
j'ai toujours admirer cette haine du goto, venant de personne qui n'ont jamais lut Dijkstra.
Dijkstra parle d'une utilisation du goto, qui remplacerais les if/else, switch/case, et autre boucles.
Aujourd'hui les utilisation principal de goto, c'est soit les goto-chain.
soit un utilisation avec des pointeur sur label pour optimiser des interpréter, soit pour des retry. mais continuons à répandre la rumeur que les goto sont héréditairement mauvais pour pas utiliser ces technique, que aucun projets sérieux ne prendrais.
ne faisons aucune exception. les try catch sont tellement moins spaghetti.
bon ça fait pas 50 raisons, mais j'ai pu donner tout mes mauvaises opinions de dev, et ca fait plaisir à étaler.