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

Posté par Irène le 21 février 2023 à 19:17. Licence CC By‑SA.

Étiquettes :

fév.

2023

Bonjour,
Ce journal est pour s'amuser un peu.

Cet article a été initialement publié sur le site PVS-Studio. J'ai traduit et publié cet article ici avec l'autorisation du détenteur des droits d'auteur parce que je voulais partager cet article drôle avec la communauté française.

J'espère que vous apprécierez ce journal !

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}
Utilisez 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 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 !

# Ah le point 4 !

Posté par Ysabeau 🧶 (site web personnel, Mastodon) le 21 février 2023 à 19:33. Évalué à 7.

Merci pour ce journal.

Je n'ai, évidemment, pas tout compris. Mais ça n'a aucune importance et ça m'a bien amusée quand même. On pourrait faire la même chose avec l'usage de la bureautique.

Le point 4 par exemple, fait penser aux gens qui désactivent le correcteur orthographique, grammatical et orthotypographique parce que ça les dérange et qu'il souligne trop de trucs (un indice, c'est peut-être justement une bonne raison de le garder).

Le point 7 sur les caractères invisibles, a contrario fait penser aux personnes qui ne les affichent pas parce que, voir plus haut.

« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
- [^] # Re: Ah le point 4 !
  
  Posté par abriotde (site web personnel, Mastodon) le 23 février 2023 à 16:34. Évalué à 5.
  
  Le plus drôle c'est que même si ce n'est pas propre et tout et tout, la plus part des trucs peuvent arriver.
  
  Désactiver les warnings, ça peut arriver au moins pour certains types de warning (par exemple en reprenant du vieux code pour un ajout/débug)
  
  "Utilisez les caractères invisibles dans votre code", ça je trouve ça vraiment piège. Avec UTF-8 tu peux nommer des variables avec un caractère invisible mais aussi 2 variables avec des caractères très semblables… Ca il y a vraiment aucune raison que ce soit bon.
  
  Connaissez-vous:
  https://fr.wikipedia.org/wiki/International_Obfuscated_C_Code_Contest
  
  Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
- [^] # Re: Ah le point 4 !
  
  Posté par Gil Cot ✔ (site web personnel, Mastodon) le 23 février 2023 à 23:36. Évalué à 2.
  
  Il y a souvent un problème d’accessibilité pour ces points évoqués. Perso, je trouve que ces soulignements rendent la relecture difficile quand ce n’est pas carrément la saisie qui est affectée (surtout quand ça fait des faux alors que tu n’as pas fini d‘écrire le mot ou la phrase…) ; J’aime mieux quand ces correcteurs ne sont activés qu’à la demande ou au moment de l’enregistrement par exemple.
  
  “It is seldom that liberty of any kind is lost all at once.” ― David Hume
# waitpid until vendredi bordel

Posté par rycks le 21 février 2023 à 19:49. Évalué à 8.

Tout est dans le sujet !

eric.linuxfr@sud-ouest.org
# Make coding fun again

Posté par Marotte ⛧ le 21 février 2023 à 20:24. Évalué à 10.

Mal écrire du C++ c’est un peu trop facile.

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 Python, qui permet d’utiliser un smiley ou un autre symbole cryptique comme nom de variable.
- [^] # Re: Make coding fun again
  
  Posté par cg le 21 février 2023 à 22:27. Évalué à 10.
  
  C'est donc toi l'auteur du petit livre gratuit How to make mistakes in Python ?
- [^] # Re: Make coding fun again
  
  Posté par 2PetitsVerres le 28 février 2023 à 12:08. Évalué à 4.
  
  Utilisez Python, qui permet d’utiliser un smiley ou un autre symbole cryptique comme nom de variable.
  
  On peut faire des choses amusantes avec des smileys en C++ aussi https://godbolt.org/z/vGTnj1fPW
  
  Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
# pas lut mais

Posté par uso (site web personnel) le 21 février 2023 à 21:04. Évalué à 0.

j'ai pertinenté, parce-que c'est trop bien ce genre de journal:
des mauvais idée pour développer… qui en vrais sont une manière détournée de donner des vrais conseilles. mais des-fois les mauvaises pratiques peuvent vraiment avoir leurs utilités.
(qui n'a jamais utiliser des pointeur de label pour optimiser une VM ?)

Je dit OUI.

bon enfin je devrais lire le journal avant de poster le commentaire.
Ok ce commentaire est con, je vais pas le poster et le su
- [^] # Re: pas lut mais
  
  Posté par Thomas Douillard le 22 février 2023 à 09:32. Évalué à 2.
  
  (Que quiconque qui n’a jamais optimisé de VM se dénonce !)
# Lien avec traceur

Posté par Anonyme le 21 février 2023 à 21:28. Évalué à 3. Dernière modification le 21 février 2023 à 21:33.

Pour la modération: le premier lien vers PVS-studio contient des traceurs qu'il serait bon de retirer.

Merci Irène pour la traduction ! peut on avoir un lien vers l'article original ?
- [^] # Re: Lien avec traceur
  
  Posté par Ysabeau 🧶 (site web personnel, Mastodon) le 21 février 2023 à 21:33. Évalué à 5.
  
  C'est fait !
  
  « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
- [^] # Re: Lien avec traceur
  
  Posté par Anonyme le 21 février 2023 à 21:42. Évalué à 10.
  
  Est-ce que je me trompe quand je suppose que tu es Irina Borisova, traductrice faisant partie de l'équipe du site PVS-Studio ?
  
  Si c'est le cas, compte tenu de la mise en place des traceurs dans le premier lien de ton journal, peux-tu nous indiquer si ce journal fait partie d'une campagne de promotion de votre site et de vos produits à l'attention des développeurs francophones ?
  
  Merci d'avance pour ta réponse.
  - [^] # Re: Lien avec traceur
    
    Posté par Irène le 22 février 2023 à 08:32. Évalué à 6.
    
    Bonjour Pierre Maziere,
    
    Oui, c'est vrai. Je travaille comme traductrice à PVS-Studio.
    
    Et oui, il y avait un traceur dans le premier lien. Cependant, s'il est interdit de placer des traceurs dans les liens, je ne le ferai plus. Comme je suis une nouvelle venue, je ne le savais pas. Ce journal est, tout d'abord, juste une collection amusante de mauvais conseils, mais j'ai décidé qu'il était également nécessaire d'indiquer la source de l'article et de placer le lien parce que je ne suis pas l'auteur de ce journal.
    
    Si j'ai fait quelque chose de mal ou enfreint les règles - je peux essayer de le corriger ou de supprimer cet article.
    
    Merci pour votre commentaire !
    - [^] # Re: Lien avec traceur
      
      Posté par YBoy360 (site web personnel) le 22 février 2023 à 19:07. Évalué à 7.
      
      On a le droit de faire du prosélytisme pour sa boite, mettre des liens et des trackers, faire croire que c'est intéressant, de se présenter en annonçant "spontanément j'ai traduit l'article que cette gentille boite m'a autorisé à partager". On peut même arriver à être confus, "je savais pas …".
      
      Après si vous voulez recruter, c'est bien vu apparemment ici. La notation des journaux en atteste. C'est un peu triste.
      - [^] # Re: Lien avec traceur
        
        Posté par Ysabeau 🧶 (site web personnel, Mastodon) le 22 février 2023 à 20:19. Évalué à 4. Dernière modification le 22 février 2023 à 20:23.
        
        Enfin, les liens traceurs ce sont des pratiques de voyou d'une manière générale. Je pourrais comprendre ça de sites qui paient de la publicité et qui veulent voir si c'est ou pas de l'argent fichu en l'air, mais absolument pas de ce genre de site.
        
        « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
        
        [^] # Re: Lien avec traceur
        
        Posté par pulkomandy (site web personnel, Mastodon) le 23 février 2023 à 23:17. Évalué à 8.
        
        Ça permet de savoir qui a cliqué sur ce lien. Que ça soit de la publicité payante ou pas, c'est intéressant pour savoir s'il faut faire plus de communication ici où si ça sert à rien.
        
        Est-ce que c'est indispensable? probablement pas, mais c'est dans les habitudes des gens qui font de la publicité. Sans toujours savoir quoi faire des résultats collectés, d'ailleurs.
- [^] # Re: Lien avec traceur
  
  Posté par Gil Cot ✔ (site web personnel, Mastodon) le 22 février 2023 à 00:55. Évalué à 2. Dernière modification le 22 février 2023 à 00:56.
  
  peut on avoir un lien vers l'article original ?
  
  J’ai trouvé ceci, puis ceci, après avoir suivi le lien sur l’auteur.
  
  “It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Quelques améliorations

Posté par GuieA_7 (site web personnel) le 21 février 2023 à 21:56. Évalué à 9.

Utilisez des nested macros partout

Utilisez des macros imbriquées partout

Utilisez des nombres en programmation.

Utilisez des nombres en dur (? directement? littéraux?).

Utilisez le moins possible de accolades et de line breaks.

Utilisez le moins possible d'accolades et de sauts de ligne.

N'utilisez pas la bibliothèque standard de langues.

N'utilisez pas la bibliothèque standard du langage.

Si line breaks et indents sont insignifiants […]

Si les sauts (passages?) de ligne et l'indentation sont insignifiants […]
- [^] # Re: Quelques améliorations
  
  Posté par palainp le 21 février 2023 à 22:02. Évalué à 5.
  
  Il est également préférable de se limiter au type void*.
  
  Tout définir en void* a l'avantage de permettre de traiter une variable entière en flottant ou tableau, et se rapprocher un peu de Perl!
- [^] # Re: Quelques améliorations
  
  Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) le 22 février 2023 à 10:02. Évalué à 6. Dernière modification le 22 février 2023 à 10:05.
  
  Récrire ce texte dans la langue de Molière risque de requérir pas mal d'efforts. Il s'agit apparemment du résultat d'un processus appliquant à la traduction le même genre de conseils, mutatis mutandis, que ceux proposés pour le C⁺⁺. Ça produit un français déroutant, et il est vraisemblable que beaucoup d'outils automatiques n'auraient pas fait pire. Ceci dit, ça reste de la bonne communication. Le texte drôlatique peut s'avérer utile (même s'il reste bien plus lisible en anglais), le sujet est approprié pour Linuxfr ; de surcroît l'entreprise semble avoir une culture de promotion via sa contribution au libre, et fait l'effort de publier dans la bonne langue en s'affichant plutôt ouvertement ; du SEO de qualitay ; ne boudons pas notre plaisir.
  
  PS : pour un incipit vraiment franc il eût fallu écrire
  
  « Ce journal est pour [nous faire connaître en vous] amus[ant] un peu. »
  
  « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
- [^] # Re: Quelques améliorations
  
  Posté par pulkomandy (site web personnel, Mastodon) le 22 février 2023 à 11:14. Évalué à 5.
  
  Si vous avez d'autres idées pour créer sh*tcode,
  
  Si vous avez d'autres idées pour créer du code de m*rde,
# tout lu mais

Posté par uso (site web personnel) le 22 février 2023 à 00:15. É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++"

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.

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.

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.
- [^] # Re: tout lu mais
  
  Posté par barmic 🦦 le 22 février 2023 à 08:10. Évalué à 6.
  
  j'ai toujours admirer cette haine du goto, venant de personne qui n'ont jamais lut Dijkstra.
  
  Même ici c'est une référence très peu lue. J'en ai fais les frais en essayant de reprendre à mon compte l'expression "X is considered harmful"…
  
  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.
  
  Les try-catch offrent bien moins de possibilités pour avoir un code spaghetti que des goto.
  
  Je trouve pas gênant le fait de proscrire le goto. Ça pousse à ne s'en servir que dans des cas où tu en a réellement besoin. Une part non négligeable des structures de contrôle ont était conçues pour éviter les goto, il faut une bonne raison pour repasser au goto.
  
  Bon après moi, je trouve que rien ne battra le duff's device en terme de code spaghetti et il n'a pas besoin de goto.
  
  https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
  - [^] # Re: tout lu mais
    
    Posté par pulkomandy (site web personnel, Mastodon) le 22 février 2023 à 14:57. Évalué à 7.
    
    Bon après moi, je trouve que rien ne battra le duff's device en terme de code spaghetti et il n'a pas besoin de goto.
    
    Ah si on peut faire pire, il y a les coroutines en C de Simon Tatham
    
    Of course, this trick violates every coding standard in the book. Try doing this in your company's code and you will probably be subject to a stern telling off if not disciplinary action! You have embedded unmatched braces in macros, used case within sub-blocks, and as for the crReturn macro with its terrifyingly disruptive contents . . . It's a wonder you haven't been fired on the spot for such irresponsible coding practice. You should be ashamed of yourself.
    Any coding standard which insists on syntactic clarity at the expense of algorithmic clarity should be rewritten. If your employer fires you for using this trick, tell them that repeatedly as the security staff drag you out of the building.
    - [^] # Re: tout lu mais
      
      Posté par Olivier Abad le 22 février 2023 à 17:59. Évalué à 2.
      
      Moi j'aime bien la "fast inverse square root" de quake 3
      
      Fast_inverse_square_root
    - [^] # Re: tout lu mais
      
      Posté par uso (site web personnel) le 22 février 2023 à 22:36. Évalué à 4.
      
      Je connaissais et j'aime beaucoup.
      
      C'est parce-que tu peu faire de genre de dinguerie, que les macro me manque dans n'importe quel langages qui n'est pas C.
      
      une autre "lib" que j'aime beaucoup, qui fait un gros usage des macro, c'est queue.h de bsd (mais dans la glibc, et aussi single-file lib) https://github.com/openbsd/src/blob/master/sys/sys/queue.h
      - [^] # Re: tout lu mais
        
        Posté par barmic 🦦 le 24 février 2023 à 06:37. Évalué à 2.
        
        C'est parce-que tu peu faire de genre de dinguerie, que les macro me manque dans n'importe quel langages qui n'est pas C.
        
        Vu le fonctionnement des macros du C, tu peux palier ce problème en utilisant m4 avec n'importe quel langage.
        
        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
        
        [^] # Re: tout lu mais
        
        Posté par uso (site web personnel) le 24 février 2023 à 09:48. Évalué à 1. Dernière modification le 24 février 2023 à 09:48.
        
        ouais, mais ça reste toujours compliquer de rajouter un outil externe dans une chaine de compilation.
        
        surtout si t'est pas sur un langage compilé.
        
        la au moins tu sais que t'auras pas à galérer à résoudre tes macro.
        
        [^] # Re: tout lu mais
        
        Posté par barmic 🦦 le 24 février 2023 à 10:25. Évalué à 2.
        
        En vrai je pense qu'il n'y a pas de difficulté particulière.
        
        Il n'y a pas d'intégration particulière entre la phase de préprocessing et le reste des compilations C et C++.
        
        Tu peux tout a fait faire un makefile qui va lancer m4 ou cpp puis le compilateur du langage tu dois juste avoir une syntaxe du préprocesseur correct, mais c'est ce que tu fait déjà en C. Ça va être un peu moins organique parce que l'import d'un module dans un langage est différent d'un #include de cpp donc tu utilisera include uniquement pour les macro, mais ça parait pas être une gymnastique si compliquée.
        
        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
        
        [^] # Re: tout lu mais
        
        Posté par pulkomandy (site web personnel, Mastodon) le 24 février 2023 à 13:06. Évalué à 4.
        
        En théorie oui, mais en pratique pas vraiment.
        
        Le préprocesseur C (cpp) est de plus en plus intégré avec la suite de la compilation. Par exemple in insère des directives permettant au compilateur de savoir à quelle ligne de quel fichier le code se trouvait avant le pré-processing, ce qui permet d'afficher des messages d'erreurs avec les bons noms de fichiers et numéros de lignes.
        
        La plupart des langages de programmation n'apprécient pas trop de se retrouver avec des #file et des #line un peu partout dans le code.
        
        Avec m4, ça fonctionne, mais la syntaxe de m4 fait que l'intégration avec autre chose peut vite être compliquée. On a vite fait de se retrouver avec une macro qui est remplacée à un endroit où on ne voulait pas. Et puis la syntaxe ne fait pas vraiment rêver de toutes façons.
        
        [^] # Re: tout lu mais
        
        Posté par barmic 🦦 le 24 février 2023 à 13:26. Évalué à 2.
        
        La plupart des langages de programmation n'apprécient pas trop de se retrouver avec des #file et des #line un peu partout dans le code.
        
        Ça demande à ajouter une option pour ne pas les avoir.
        
        Et puis la syntaxe ne fait pas vraiment rêver de toutes façons.
        
        Parce qu'il y a des gens qui trouvent celle de cpp magnifique ? Sans jugement de valeur de ma part, aucune des 2 syntaxes ne me fais me réveiller la nuit.
        
        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
      - [^] # Re: tout lu mais
        
        Posté par uso (site web personnel) le 24 février 2023 à 09:44. Évalué à 2.
        
        Je connaissais et j'aime beaucoup.
        
        *Je connaissais pas.
        
        j'ai oublié la négation, mais c'est un peu naze ces langue ou une négation peu changer le sens d'une phrases.
        
        [^] # Re: tout lu mais
        
        Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) le 24 février 2023 à 12:10. Évalué à 6.
        
        :-)
        C'est pour ça qu'un mécanisme de redondance est inclus :
        
        « Je ne connaissais pas. »
        
        « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
        
        [^] # Re: tout lu mais
        
        Posté par Gil Cot ✔ (site web personnel, Mastodon) le 24 février 2023 à 13:50. Évalué à 2.
        
        oui faut redonder sans doubler : ça fait bizarre quand on apprend cette langue, puis bizarre quand on découvre que les « locutrices natives et locuteurs natifs » préfèrent trop souvent ne pas s'infliger ce redoublement /m\
        
        “It is seldom that liberty of any kind is lost all at once.” ― David Hume
        
        [^] # Re: tout lu mais
        
        Posté par Tit le 24 février 2023 à 14:46. Évalué à 3.
        
        En suivant ton lien je trouve que "« Paul ne sait pas s'il ne va pas s'arrêter de travailler »
        c'est un peu petit joueur, on pourrait dire « Paul ne sait pas s'il ne va pas ne pas continuer à travailler »
        
        [^] # Re: tout lu mais
        
        Posté par Claude SIMON (site web personnel) le 24 février 2023 à 14:55. Évalué à 4.
        
        En capillotractant un peu : « Paul ne sait pas s'il ne va pas ne pas continuer à ne pas chômer ».
        
        Pour nous émanciper des géants du numérique : Zelbinium !
        
        [^] # Re: tout lu mais
        
        Posté par Benoît Sibaud (site web personnel) le 24 février 2023 à 14:59. Évalué à 5.
        
        Faut rajouter « , sait-il ? » à la fin pour clarifier.
  - [^] # Re: tout lu mais
    
    Posté par uso (site web personnel) le 22 février 2023 à 23:16. Évalué à 4.
    
    Je trouve pas gênant le fait de proscrire le goto. Ça pousse à ne s'en servir que dans des cas où tu en a réellement besoin.
    
    Je pourrais être d'accord si les goto étaient encore utilisé comme ils l'étaient dans les années 60s, c'est à dire par des personnes venant de l'asm qui utilisaient goto, comme on utilise les jmp en assembleur. pour exprimer le code flow du programme.
    
    le truck, c'est que goto a déjà une mauvaise réputation, et je voie vraiment pas quelqu'un faire un goto, la ou il pourrait faire un if, ou une boucle.
    Avec un langages moderne (C++90, ou GNU C) on peu utiliser des mécanisme de RAII/defer ou autre, ce qui rend goto encore moins utile même pour gérer des erreurs.
    
    Mais a coté de ça, j'ai vu plein de gents faire de la gestion d'erreur catastrophique en C, par peur des goto.
    Je trouve aussi que le goto again a aussi un coté plus "code auto-documenté" qu'un do while() quand on veut exprimer des retry dans un programme.
    
    Donc au final proscrire les goto, je trouve que ça protège pas vraiment des utilisation "sale" de goto, mais en empêche ces utilisation "légitime".
    
    Les try-catch offrent bien moins de possibilités pour avoir un code spaghetti que des goto.
    
    ce que je trouve bizarre avec les exceptions, c'est qu'elle évite les pire cotés du goto, elle permettent pas de remonter le flow du programme.
    
    mais elle ont aussi un des coté spaghettisant que goto n'a pas, car C a évacué ça dans setjmp/longjmp, c'est la possibilité de sauter d'une fonction à une autre.
    - [^] # Re: tout lu mais
      
      Posté par barmic 🦦 le 23 février 2023 à 17:34. Évalué à 7.
      Je trouve aussi que le goto again a aussi un coté plus "code auto-documenté" qu'un do while() quand on veut exprimer des retry dans un programme.
      
      C'est très subjectif do { something } while (success); C'est très lisible et de manière factuelle :
      
      le code que tu rééxecute est matérialisé
      
      la condition est aussi plus mise en valeur
      
      Mais a coté de ça, j'ai vu plein de gents faire de la gestion d'erreur catastrophique en C, par peur des goto.
      
      Est-ce que quelqu'un capable de faire une gestion d'erreur catastrophique sera en mesure de maintenir un code avec des goto ? Parce que c'est la maintenance qui est complexe. Quand tu écris ton snipet de code avec un goto ce sera toujours simple et lisible, mais c'est maintenir cette simplicité et cette lisibilité qui est un vrai enjeux.
      
      Donc au final proscrire les goto, je trouve que ça protège pas vraiment des utilisation "sale" de goto, mais en empêche ces utilisation "légitime".
      
      Comme toutes les règles de développement, il y a un moment où tu acquière la maturité pour savoir que ces règles signifient « utilise si tu sais ce que tu fait ».
      
      mais elle ont aussi un des coté spaghettisant que goto n'a pas, car C a évacué ça dans setjmp/longjmp, c'est la possibilité de sauter d'une fonction à une autre.
      
      Elles ne font que remonter la pile d’exécution ce n'est pas un saut arbitraire.
      
      Après on tourne autour de :
      
      les bons développeurs écrivent du code de plutôt bonne qualité quelque soit le langage
      
      les mauvais développeurs écrivent du code de plutôt mauvaises qualité quelque soit le langage
      
      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
      - [^] # Re: tout lu mais
        
        Posté par pulkomandy (site web personnel, Mastodon) le 23 février 2023 à 23:24. Évalué à 5.
        
        Pour moi le code avec des goto pour gérer les erreurs est beaucoup plus simple à comprendre et à maintenir.
        
        C'est peut-être juste une question d'habitude.
        
        On ne fait bien sur pas n'importe cuoi avec des goto dans tous les sens. Seulement des goto qui vont vers la fin de la fonction, pour faire les libérations de ressources nécessaires avant d'en sortir. C'est bien sûr avantageusement remplacé par la RAII en C++, mais en C, on a pas ce luxe.
        
        Si on utilise pas de goto, on a deux choix:
        
        tout le code se retrouve imbriqué dans un tas de if() qui ne servent qu'à gérer les erreurs, on a du mal à suivre le flot du code au milieu
        
        le nettoyage est fait à plein d'endroits dans la fonction (partout où une erreur peut se produire) avec beaucoup de code dupliqué
        
        [^] # Re: tout lu mais
        
        Posté par barmic 🦦 le 24 février 2023 à 06:34. Évalué à 2.
        
        L'instruction goto existe dans bien d'autres langages. En go, en perl, en php, en C#, en ada,… Des langages qui ont d'autres alternatives et qui pour certains expliquent eux-mêmes qu'il vaut mieux lui préférer d'autres constructions.
        
        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
- [^] # Re: tout lu mais
  
  Posté par gUI (Mastodon) le 22 février 2023 à 08:14. Évalué à 6. Dernière modification le 22 février 2023 à 08:29.
  
  Idem, je suis un fervent défenseur de l'utilisation (raisonnée bien évidemment) des goto, des variables globales, et même du code à plat.
  
  Quand je vois les propositions d'optimisation je rigole :
  - illisible
  - le processeur exécute au moins autant (et souvent plus) de if
  
  Lisez bien les commentaires : les vraies corrections (la partie && pourcentage <= est inutile, et il affiche la barre complète alors qu'on n'est qu'à 91%) sont arrivées bien tard dans la conversation.
  
  Mais comme toi je viens de l'embarqué, sûrement pas un hasard…
  
  Et perso je rajouterais même (en provoquant un poil) :
  
  14 - Utilisez les virgules flottantes, c'est génial, on peut calculer la masse de l'univers mais on peut pas faire 2 - 1.8 - 0.2
  
  En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
  - [^] # Re: tout lu mais
    
    Posté par Julien Jorge (site web personnel) le 24 février 2023 à 11:39. Évalué à 4.
    
    Idem, je suis un fervent défenseur de l'utilisation (raisonnée bien évidemment) des goto, des variables globales, et même du code à plat.
    
    Je ne connaissais pas cet exemple, ça fait 10 minutes que je boucle entre « c'est pourri » et « c'est parfait » :D D'un côté c'est très répétitif et on a envie d'y mettre une boucle, de l'autre côté c'est tellement simple qu'on comprend l'intention au premier coup d'œil.
    
    Lisez bien les commentaires : les vraies corrections (la partie && pourcentage <= est inutile, et il affiche la barre complète alors qu'on n'est qu'à 91%) sont arrivées bien tard dans la conversation.
    
    Mmmh on ne va pas sortir trop tôt si on enlève le && percentage <= ? J'aurais plutôt enlevé le percentage > x &&.
    
    Pour la barre complète à 91% je pense que ça peut s'expliquer par un ressenti utilisateur. Vaut-il mieux afficher 100% dès 91% (et l'utilisateur se demande « bah alors c'est fini ou pas ? » pendant 10%) ou rester à 0% jusqu'à avoir atteint 10% (et l'utilisateur se demande « bah alors ça commence ou quoi ? » pendant 10%) ?
    - [^] # Re: tout lu mais
      
      Posté par pulkomandy (site web personnel, Mastodon) le 24 février 2023 à 13:35. Évalué à 2.
      Allez je tente une version sans conditions et sans boucles:
      
      #include <locale.h> #include <math.h> #include <stdio.h> #include <wchar.h> static const wchar_t* const progressBar = L"🔵🔵🔵🔵🔵🔵🔵🔵🔵🔵⚪⚪⚪⚪⚪⚪⚪⚪⚪⚪"; void GetPercentageRounds(double progress) { int intProgress = round(progress * 10); wprintf(L"%-.10ls (%lf)\n", &progressBar[10 - intProgress], progress); } int main () { setlocale(LC_ALL, ""); for (double progress = 0; progress < 1; progress += 0.1) GetPercentageRounds(progress); }
      - [^] # Re: tout lu mais
        
        Posté par barmic 🦦 le 24 février 2023 à 14:02. Évalué à 4.
        
        Pas de boucle, pas de condition, pas d'ésotérisme et la possibilité de choisir la longueur.
        
        String GetPercentageRounds(double progress, int width = 10) { def size = Math.round(progress / width) return '🔵' * size + '⚪' * (width - size) }
        
        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
        
        [^] # Re: tout lu mais
        
        Posté par Julien Jorge (site web personnel) le 24 février 2023 à 14:15. Évalué à 3.
        
        C'est déjà overkill puisque cela couvre des cas non nécessaires :)
        
        [^] # Re: tout lu mais
        
        Posté par Benoît Sibaud (site web personnel) le 24 février 2023 à 14:57. Évalué à 6.
        
        width = 0 ou -10 ? progress = -1.0, NaN, -Infinity ? width doit être inférieur à la taille max de String aussi (et petit de préférence sinon ça devrait se sentir aussi). Et on devrait pouvoir choisir la forme donc avoir un nom de fonction en template, et la couleur devrait être un paramètre, et on devrait pouvoir choisir la forme et la couleur de l'abri à vélo vert.
        
        [^] # Re: tout lu mais
        
        Posté par barmic 🦦 le 24 février 2023 à 15:58. Évalué à 2.
        
        width = 0 ou -10 ? progress = -1.0, NaN, -Infinity ? width doit être inférieur à la taille max de String aussi (et petit de préférence sinon ça devrait se sentir aussi).
        
        La plupart des cas décrit vont générer un IllegalArgumentException, si tu lui donne des nombre trop surprenant tu va prendre une ArithmeticException ce à quoi tu doit t'attendre quand tu manipule de NaN ou des Infinite.
        On pourrait min/max progress pour aider l'utilisateur.
        La taille maximale d'une String est égale à la taille à la valeur maximale d'un Integer.
        
        Et on devrait pouvoir choisir la forme donc avoir un nom de fonction en template, et la couleur devrait être un paramètre, et on devrait pouvoir choisir la forme et la couleur de l'abri à vélo vert.
        
        Non. Prendre en paramètre ce genre de format c'est le meilleur moyen de créer des failles plus ou moins béantes.
        
        Rendre paramétrable quelque chose qui ne te coûte rien n'a rien à avoir avec le fait d'ajouter des fonctionnalité potentiellement dangereuses sans quelles aient étaient demandé.
        
        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
      - [^] # Re: tout lu mais
        
        Posté par Julien Jorge (site web personnel) le 24 février 2023 à 14:13. Évalué à 4.
        
        Mais cela n'est pas équivalent puisque la version originale retourne la chaîne alors que toi tu l'affiches directement :)
        
        [^] # Re: tout lu mais
        
        Posté par pulkomandy (site web personnel, Mastodon) le 24 février 2023 à 16:51. Évalué à 3.
        
        Oui, ça devenait trop compliqué sinon. Peut être en retournant un std::wstring_view?
        
        Et ma version fait n'importe quoi si on demande un progress supérieur à 1 ou négatif ou…
        
        Comme quoi l'implémentation proposée n'est probablement pas la plus bête.
        
        Au passage j'ai découvert quelques trucs sur la gestion des chaînes de wchar_t que je ne manipule pas souvent:
        
        On ne peut pas faire un printf avec un %ls pour afficher un wchar_t, ou en tout cas ça fait des trucs bizarres avec le modificateur de longueur, un %.10ls n'affiche pas 10 caractères. Avec wprintf ça semble fonctionner.
        
        Il faut faire un setlocale, sinon le printf ou wprintf refuse d'afficher la chaîne. Je ne savais pas que printf pouvait retourner une erreur (en y réfléchissant ça semble logique, mais je m'étais pas posé la question).
  - [^] # Re: tout lu mais
    
    Posté par Faya le 24 février 2023 à 20:20. Évalué à 2.
    
    mais on peut pas faire 2 - 1.8 - 0.2
    
    Légendaire ce journal, j'ai presqu'envie de me refaire les 450 commentaires (dont plus d'1/3 de toi !)
    - [^] # Re: tout lu mais
      
      Posté par Gil Cot ✔ (site web personnel, Mastodon) le 24 février 2023 à 20:47. Évalué à 4.
      
      Ou de lire Julia Evans https://jvns.ca/blog/2023/02/08/why-does-0-1-plus-0-2-equal-0-30000000000000004/
      …puis de remarquer comment on traite la problématique de types décimaux en : Ada, C++, Rust, etc.
      
      “It is seldom that liberty of any kind is lost all at once.” ― David Hume
- [^] # Re: tout lu mais
  
  Posté par Gil Cot ✔ (site web personnel, Mastodon) le 24 février 2023 à 13:54. Évalué à 2.
  
  xkcd 292
  
  “It is seldom that liberty of any kind is lost all at once.” ― David Hume
  - [^] # Re: tout lu mais
    
    Posté par pulkomandy (site web personnel, Mastodon) le 24 février 2023 à 16:53. Évalué à 6.
    
    J'en profite pour re-partager cette image extraite d'un livre sur la programmation Forth qui ne se privait pas de taper sur les développeurs BASIC et leur code spaghetti:
    - [^] # Re: tout lu mais
      
      Posté par jmiven le 24 février 2023 à 18:57. Évalué à 5.
      
      Le livre étant, pour les curieux, Thinking Forth de Leo Brodie. :)
    - [^] # Re: tout lu mais
      
      Posté par Gil Cot ✔ (site web personnel, Mastodon) le 24 février 2023 à 20:09. Évalué à 4. Dernière modification le 24 février 2023 à 20:11.
      C'est melin :-D À noter que beaucoup de BASIC ont paré à cela
      
      ajout de GOSUB et retrait de GOTO pour obliger à utiliser des procédures
      
      suppression de la numérotation de lignes, et du coup plus de GOTO 500 et les étiquettes évitent ce désagrément lorsque le code évolue (ce qui était en 500 va se retrouver en 350 ou 970 par exemple)
      
      les deux ou d'autres approches qui ont parfois abouti à d'autres langages
      
      Et comme tout langage, Forth lui-même permet des choses étranges…
      
      “It is seldom that liberty of any kind is lost all at once.” ― David Hume
      - [^] # Re: tout lu mais
        
        Posté par cg le 25 février 2023 à 16:38. Évalué à 6.
        
        ajout de GOSUB
        
        Wow, le flash ! Je viens de me souvenir que je disais "gozub" quand j'étais petit :D
        (et gotau, bien sûr, pas gotou, mais ça c'est tout le monde hein ?).
        
        [^] # Re: tout lu mais
        
        Posté par Gil Cot ✔ (site web personnel, Mastodon) le 25 février 2023 à 16:46. Évalué à 2.
        
        Ça fait sens, et c'est en tout cas cohérent : « gotau dix » pour les francophones (pas « go tout teine » ni le mélange dans un sens ou l'autre)
        
        “It is seldom that liberty of any kind is lost all at once.” ― David Hume
      - [^] # Re: tout lu mais
        
        Posté par HL le 04 mars 2023 à 01:35. Évalué à 3.
        
        Le Basic Locomotive avait GOTO et GOSUB. :-)
        
        [^] # Re: tout lu mais
        
        Posté par Gil Cot ✔ (site web personnel, Mastodon) le 04 mars 2023 à 02:04. Évalué à 2.
        
        Arf… Ce doit être pour ça qu'on aimait le croco ;D (moi c'était parce-que c'était complet : on pouvait faire du son et de la couleur, en plus d'avoir des trucs comme LOCATE et un peu de CP/M)
        
        “It is seldom that liberty of any kind is lost all at once.” ― David Hume
        
        [^] # Re: tout lu mais
        
        Posté par Claude SIMON (site web personnel) le 04 mars 2023 à 07:52. Évalué à 2. Dernière modification le 04 mars 2023 à 07:53.
        
        Le BASIC du ZX81 avait aussi GOSUB et GOTO. Heureusement, parce qu'il avait IF … THEN … mais pas ELSE.
        
        Ce qui est amusant avec le GOTO, c'est qu'on peut lui passer une expression qui retournait un nombre. Ainsi, le programme :
        
        10 LET A=2 20 GOTO A*100 100 PRINT "A" 110 STOP 200 PRINT "B" 210 STOP 300 PRINT "C" 310 STOP
        
        affichait B.
        
        Ça permettait de simuler le ON … GOTO … d'autres BASIC, voire une forme de switch.
        
        Pour nous émanciper des géants du numérique : Zelbinium !
        
        [^] # Re: tout lu mais
        
        Posté par Gil Cot ✔ (site web personnel, Mastodon) le 04 mars 2023 à 09:30. Évalué à 2.
        
        Cette arnaque de ZX81 ne me manque pas : l'absence de ELSE obligeait à du code rallonge pour avoir des scripts portables, ou alors fallait maintenir une version Spectrum plus longue.
        
        Génial l'adresse calculée ; ça permet de faire comme des étiquettes si on défini des constantes parlantes auparavant (du coup on n'oublie pas un GOTO 500 en cas de refactoring et on ne change la définition LET WHERE=500 qu'une seule fois.) Bref, autoriser plus de discipline et de concision (comparé aux successifs IF … GOTO … pour le même résultat.)
        
        11 PRINT "1 Formule A" 12 PRINT "2 Formule B" 13 PRINT "3 Formule C" 20 PRINT "Votre Choix ?" 21 READ A 30 REM GOTO A*100 31 IF A=1 GOTO 100 32 IF A=2 GOTO 200 33 IF A=3 GOTO 300 40 PRINT "Mauvais Nombre" 99 STOP 100 PRINT "A" 110 STOP 200 PRINT "B" 210 STOP 300 PRINT "C" 310 STOP
        
        Ah oui, c'est vrai, les ON … GOTO … et ON … GOSUB … que j'ai oublié bien que présents dans : AppleSoft BASIC, Atari BASIC, etc. Ils survivent encore dans VBA…
        Effectivement, c'est un équivalent de BRANCH chez PICAXE.
        
        11 PRINT "1 Formule A" 12 PRINT "2 Formule B" 13 PRINT "3 Formule C" 20 PRINT "Votre Choix ?" 21 READ A 30 ON A GOTO 100,200,300 31 REM BRANCH A,100,200,300 32 REM ON A GOTO A*100 40 PRINT "Mauvais Nombre" 99 STOP 100 PRINT "A" 110 STOP 200 PRINT "B" 210 STOP 300 PRINT "C" 310 STOP
        
        La forme la plus avancée (proche des switch modernes) est le SELECT CASE … … END de Gambas et de VB
        
        “It is seldom that liberty of any kind is lost all at once.” ― David Hume
# composants "sous licence"

Posté par zurvan le 22 février 2023 à 09:43. Évalué à 4.

Étonnant que personne n'ait pas encore tiqué sur le "N'utilisez jamais de composants sous licence. N'utilisez que des produits pirates.".

Puisqu'il n'est pas possible de "pirater" un logiciel libre, on peut en déduire qu'ils encouragent à payer pour du logiciel proprio et utiliser des bibliothèques non libre. On pourrait traduire, dans le langage suffisant de ces "conseils avisés" :

"Utilisez des composants sous licence propriétaire. Ne les piratez pas, achetez-les au prix fort à des éditeurs renommés et oubliez qu'il existe des logiciels libres qui ne vous imposeront pas tout cela…"

« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
- [^] # Re: composants "sous licence"
  
  Posté par Zenitram (site web personnel) le 22 février 2023 à 17:30. Évalué à 2.
  
  Puisqu'il n'est pas possible de "pirater" un logiciel libre,
  
  Gni??????
  Il n'y a aucune différence entre un logiciel non libre et un logiciel libre à ce sujet.
  Rappel : un logiciel sans licence est non libre (ben oui, aucun droit conféré par défaut), un logiciel sous licence libre te permet de faire… Ce qui est autorisé dans la licence, et pas du tout plus.
  
  "Utilisez des composants sous licence propriétaire. Ne les piratez pas, achetez-les au prix fort à des éditeurs renommés et oubliez qu'il existe des logiciels libres qui ne vous imposeront pas tout cela…"
  
  Tu sous-entends par là qu'avec un logiciel sous licence libre ça n'arriverait pas, il va falloir argumenter, et comme tu sembles être sûr de toi je te propose de prendre un de mes logiciels libres et de ne pas en respecter la licence que je te file et on en reparle devant un tribunal pour qu'un juge impartial confirme (ou pas) que tu as raison.
  
  En réalité, contrairement à ce que tu penses les logiciels libres ne sont pas forcément plus utilisables pour un développeur, ça dépend (de la licence du code à soit par exemple, des fois c'est complètement incompatible, même si toi tu fais du libre)… De la licence du logiciel libre et de ce qu'elle t'autorise, et ses conditions. Et des fois, il vaut largement plus un logiciel non libre qui te permet ce que tu veux faire qu'un logiciel libre qui ne te permet pas ce que tu veux faire, car certaines licences sont assez contraignantes (et des fois c'est voulu, la version libre est la pour la pub et la thune est faite sur te vendre des libertés que la version libre n'a pas, voir par exemple le business model de MySQL).
  - [^] # Re: composants "sous licence"
    
    Posté par zurvan le 22 février 2023 à 18:20. Évalué à 3.
    
    Ils ne parlent pas de "ne pas respecter la licence", mais de "pirater". Qu'est-ce que tu peux être bête quand tu t'y mets…
    
    « Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
    - [^] # Re: composants "sous licence"
      
      Posté par Zenitram (site web personnel) le 22 février 2023 à 19:13. Évalué à 1. Dernière modification le 22 février 2023 à 19:14.
      
      En effet, je suis trop bête de ne pas comprendre la différence entre respecter une licence et respecter une licence.
      Si tu ne respectes pas ma licence libre, ou si tu fais du code GPLv3 mélangé avec du code GPLv2, tu fais du "piratage".
      
      J'imagine que les guillemets vont te permettre de trouver une pirouette pour t'en sort, il n'en reste pas moins que le fond est exactement le même : si tu ne fais pas attention à la licence et que tu ne la respecte pas, c'est problématique.
      
      Ha les prosélitistes du libre qui font croire que le libre est différent du non libre sur de trucs qui sont en réalité pareil (on a le droit de faire que ce pour quoi on a une autorisation) puis se cachent le jour où un développeur libriste se plaint du "piratage" (par exemple un code GPLv2 retrouvé dans un logiciel sans code livré) de son logiciel libre.
      
      Passons, le libre survivra (juste parfois avec des gens qui se seront fait avoir par un discours trompeur) comme le non libre survit au "piratage".
      - [^] # Re: composants "sous licence"
        
        Posté par Faya le 24 février 2023 à 17:52. Évalué à 5.
        
        Avant-propos : Dans la définition stricte du mot "piratage", tu as raison. Ne pas respecter la licence d'un logiciel libre c'est pirater ce logiciel. Maintenant quand on regarde la VO de l'argument :
        
        Never use licensed components. You can use only pirated ones. Where to find them? On suspicious websites. Why do you need to pay other programmers?
        
        On a quand même vachement l'impression que l'auteur associe forcément la qualité à "payer". Pour reprendre l'exemple de ton propre logiciel, je peux intégrer du code de qualité et sans payer ici. Donc le pirated de l'auteur a surtout l'air de concerner des produits payants et propriétaires.
        
        Si tu ne respectes pas ma licence libre
        
        Vraie question, pour ma culture : vu que la BSD 2-Clause "Simplified" License est très permissive, qu'est-ce qu'il faudrait faire pour ne PAS respecter ta licence ? Si je le modifie en conséquence, j'ai le droit de le renommer et le distribuer sous une autre licence ? Et je dis en conséquence mais genre si je renomme la totalité des variables du code tout en conservant a logique, ou je modifie juste les interfaces CLI/GUI en changeant quelques phrases/paramètres (pour obtenir un binaire différent), est-ce que c'est suffisant pour dire que c'est un autre logiciel ? En fait à part le distribuer tel quel sous une autre licence je me demande comment on peut objectivement réaliser un piratage de cette licence.
        
        [^] # Re: composants "sous licence"
        
        Posté par Zenitram (site web personnel) le 25 février 2023 à 12:27. Évalué à 2.
        
        Pour reprendre l'exemple de ton propre logiciel, je peux intégrer du code de qualité et sans payer ici.
        
        Tout ce que je produis en libre n'est pas disponible sur mon site, et n'est pas disponible gratuitement. Tu fait l'amalgame entre gratuit et libre, il peut y avoir du libre payant et du gratuit non libre.
        
        Donc le pirated de l'auteur a surtout l'air de concerner des produits payants et propriétaires.
        
        Non : payant. Libre ou pas. "payants et libre" marche aussi.
        Si l'auteur ne voulait pas faire de prosélytisme mensonger sur le libre, il aurait parlé de logiciel gratuit car c'est de ça que ça parle, pas de logiciel libre (qui peuvent être incompatibles avec le besoin de celui qui cherche).
        
        A un moment il faut arrêter les fantasmes sur le libre, le libre ce sont les 4 libertés pour celui qui reçoit un truc, et rien d'autre : pas sur le prix, pas sur la liberté totale qui permet tout, pas sur le communautaire, etc.
        
        Alors certes l'auteur initial parle de payant, mais la "correction" est complètement fausse. C'est juste de l'honnêteté intellectuelle à avoir que d'arrêter de penser que le libre est la réponse universelle (ce n'est pas du tout le cas).
        Perso je conclue surtout sur les gens qui balance du "si tu utilises du libre ça va" alors que non : ils ne croient eux-mêmes pas dans le libre, juste une idée (fausse) de ce qu'est le libre. rien de nouveau.
        
        Vraie question, pour ma culture : vu que la BSD 2-Clause "Simplified" License est très permissive, qu'est-ce qu'il faudrait faire pour ne PAS respecter ta licence ?
        
        Ne pas citer mon nom dans les copyrights. Ça arrive assez souvent et c'est de la contrefaçon / piratage.
        
        Si je le modifie en conséquence, j'ai le droit de le renommer et le distribuer sous une autre licence
        
        Enlève "modifie", tu n'as même pas besoin de ça.
        J'ai déjà croisé des libristes hurlant de trouver leur logiciel juste renommé et en vente sur des "stores", ça me fait sourire, les pauvres n'aiment pas le libre et font du libre sans comprendre ce qu'il est… Le libre est justement permettre entre autres ça, en interdisant d'interdire ça, si tu trouve ça mal c'est simple, quitte le libre, il n'est pas fait pour toi (mais du coup, tu ne pourras pas te la péter libriste, dommage…).
        Faut par contre que tu renommes : j'ai un trademark sur les marques, certains en ont subit les conséquences à vouloir me piquer le nom, le trademark n'a rien à voir avec le libre. A noter toutefois que plein de développeurs ne prennent pas la peine (cher et chiant) de poser la marque et dans ce cas c'est open bar, les autres peuvent même utiliser le nom que tu as choisis sans aucun problème, donc vendre sans faire aucune modification.
        
        En fait à part le distribuer tel quel sous une autre licence je me demande comment on peut objectivement réaliser un piratage de cette licence.
        
        Juste pour préciser : par autre licence, tu peux englober du libre , tu ferais de la contrefaçon si tu changeais la licence de mon code en GPL.
        Une histoire rigolote de licence (oui, la, j'ai dit merci à ma demande de CLA même pour ce type de licence, pour justement pouvoir faire un changement de licence). Résumé de l’anecdote : des prosélytistes copyleft pensaient que le code qu'ils payaient resteraient à vie copyleft, ils ont juste pas compris qu'ils me laissaient le copyright et que donc à la fin du contrat je faisais ce que je voulais. Anecdote pour (essayer de) faire comprendre la différence entre les fantasmes des gens sur le libre et la réalité légale. Pour revenir au sujet, prendre un logiciel à l'arrache en GPL et le mettre dans un logiciel non libre a exactement le même effet que la ligne citée, ne pas faire attention à la licence libre est le meilleur moyen de pirater un logiciel libre, libre ou pas ne change rien au piratage, sauf dans la tête de gens qui veulent faire croire que le libre serait mieux dans un truc qui n'a rien à voir avec le libre.
        
        PS : j'ai répondu parce que tu avais une "vraie question", mais je m'arrêterai quand même la même si tu en as une autre, je sais qu'ici la réalité est très adaptée quand elle ne plaît pas, j'essaye de me sevrer un peu de rentrer dans le tas.
        
        [^] # Re: composants "sous licence"
        
        Posté par Faya le 25 février 2023 à 17:50. Évalué à 2.
        
        Tu fait l'amalgame entre gratuit et libre, il peut y avoir du libre payant et du gratuit non libre.
        
        Je ne fais pas l'amalgame, j'ai choisi sciemment du libre et gratuit. Parce que l'auteur parle de payant. On connaît (surtout ici) les nombreux exemples de libre payant.
        
        j'ai répondu parce que tu avais une "vraie question", mais je m'arrêterai
        
        Merci. Là on parle juste de trucs juridiques et factuels, il n'y a pas vraiment de débat sur l'esprit du libre et autres trucs annexes sources de désaccords. Bon c'est dommage parce qu'il me restait une question : "Tu ferais de la contrefaçon si tu changeais la licence de mon code en GPL." uniquement si je changeais la licence de ton code sans modification, non ? Si je le prends, le modifie, le renomme, et le met dans un nouveau programme, je peux relicencier comme je veux ?
        
        [^] # Re: composants "sous licence"
        
        Posté par Zenitram (site web personnel) le 26 février 2023 à 12:19. Évalué à 6. Dernière modification le 26 février 2023 à 12:20.
        
        Très HS mais comme demandé gentiment.
        Ma compréhension suite aux différentes histoires de licences, n’hésitez pas à contre-argumenter si vous avez des contre-arguments, est :
        
        uniquement si je changeais la licence de ton code sans modification, non ? Si je le prends, le modifie, le renomme, et le met dans un nouveau programme, je peux relicencier comme je veux ?
        
        Non, car la BSD n'autorise pas le "sublicensing", c'est une des rares et subtiles différences entre BSD et MIT.
        De souvenir il y a un qui avait essayé sur un fichier de Linux de changer la licence d'un fichier sous BSD en GPL suite à une modif, et ça s'est mal passé.
        - le code original BSD reste sous BSD
        - ta potentielle modif peut être sous GPL, mais n'enlève pas la licence du code original (si tu joues à ça, faut faire un truc style "BSD sauf mon code qui est sous GPL, regardez qui a fait quoi pour savoir" (en pratique c'est chiant!)
        - le livrable est alors sous GPL, mais n'enlève pas la licence BSD du code pas à toi
        
        Dans mon exemple des emmerdeurs qui voulaient tout GPL, pas une ligne avec du "méchant copyfree", on avait respecté ça, évité le code BSD sauf le mien (je peux légalement changer la licence de mon code non pas grâce à BSD mais parce que je suis ayant droit) et pris du code GPL ou MIT (qu'on a mis en GPL grace au mot "sublicense" de la MIT). Ça reste chiant, on a remis les licences originales à la fin du projet.
        
        Hors CC0, le libre est différent, pas mieux, sur les sources de conflits quand à l'usage (faut bien regarder la licence pour savoir ce que tu as le droit de faire ou pas, et des fois une licence non libre te laisse bien plus de libertés par rapport à ce que tu veux faire au final).
        
        [^] # Re: composants "sous licence"
        
        Posté par Faya le 26 février 2023 à 13:22. Évalué à 4.
        
        grâce au mot "sublicense" de la MIT
        
        Ah voilà c'est ça l'info qu'il me manquait, je comprends mieux. Parce que je lis que les licence non-copyleft permette de "refermer" du code libre mais en fait c'est faux au moins dans le cas de la BSD. La licence reste.
        
        [^] # Re: composants "sous licence"
        
        Posté par Zenitram (site web personnel) le 26 février 2023 à 14:48. Évalué à 4. Dernière modification le 26 février 2023 à 14:49.
        
        Parce que je lis que les licence non-copyleft permette de "refermer" du code libre mais en fait c'est faux au moins dans le cas de la BSD. La licence reste.
        
        tu mélanges 2 choses, la licence et le code :
        - un code BSD restera BSD (pas du "sublicensing"), donc si A file un code BSD à B qui file à C avec modif GPL, tu pourras récupérer le code de A en BSD (note : en théorie, car en pratique c'est un peu la merde car généralement tu as le fichier source sans précision de quoi est à qui, la je ne sais pas légalement ce que C peut demander à B… Cas théorique, faut que le ce cas arrive + gestionnaire de version non public, je doute qu'il y ai ce cas en pratique)
        - le "si" précédent est important pour "refermer", car le fichier source modifié en non public, tu n'as pas accès au code, donc si A file un code BSD à B qui file à C le binaire compilé, C n'a pas légalement accès au code de A (le code de A est de fait "refermé" dans la chaîne de transmission), la licence reste mais C n'a que la licence (qui ne peut pas être "refermée"), pas le code (qui peut l'être, et c'est ce dont les gens parlent généralement).
        
        Donc, non, ce n'est pas faux en pratique, le code BSD peut se faire "refermer".
        Mais pour embêter les pro copyleft, n'oublions pas que du code GPL peut aussi se retrouver "refermé", personne à part Google a le code GPL modifié de Linux, car Google ne file pas de binaire, juste le résultat, du coup un code GPL "je veux pas que ça soit utilisé pour du non libre" peut être utilisé "refermé" dans le cas d'un service (d'où l'AGPL pour contrer ça, mais peu utilisé même par les plus partisans du copyleft, la je sèche sur pourquoi les plus partisans du copyleft ne font pas plus souvent de l'AGPLv3).
        
        [^] # Re: composants "sous licence"
        
        Posté par BAud (site web personnel) le 26 février 2023 à 15:04. Évalué à 4.
        
        je lis que les licence non-copyleft permette de "refermer" du code libre mais en fait c'est faux au moins dans le cas de la BSD. La licence reste.
        
        nope, c'est vrai pour le code livré sous forme compilée et qu'il n'y a personne pour fournir le code source à celui qui n'a que le binaire :/ La licence a beau rester, tu ne peux que redistribuer le binaire fourni, pas vraiment le modifier à partir des sources (adieux aux évolutions, correctifs de sécurité, prise en compte de nouvelles versions de l'upstream…)
        
        La BSD-2 clause reste très bien pour du code interprété : le livrable est le code source, tant qu'il n'y a pas d'obfuscation à fourniture de l'exécutable :D
# JavaScript

Posté par Guillaume Denry (site web personnel) le 22 février 2023 à 09:49. Évalué à 10.
Je vous propose de faire pareil pour JavaScript, mais avec un seul conseil :
1. Utilisez JavaScript
- [^] # Re: JavaScript
  
  Posté par BAud (site web personnel) le 26 février 2023 à 15:09. Évalué à 5.
  Il y en a une similaire avec PHP :
  1. Continuez à utiliser PHP 3 (ou 4 voire 5 ou même 7) — cf. ce journal
# Mention spéciale pour la 45

Posté par Enzo Bricolo 🛠⚙🛠 le 22 février 2023 à 11:40. Évalué à 8.

Elle marche avec tous les langages du COBOL au RUST et à tous les niveaux du débutant de la veille au tenix ninja.
Elle a montré sa capacité de nuisance dans tous les domaines, des banques qui coulent, des trains qui déraillent, des fusées qui épinglent …
Elle marchent même dans les formulaires en papier des parents d'élèves …
# 1 conseil pour donner des conseils

Posté par YBoy360 (site web personnel) le 22 février 2023 à 16:51. Évalué à 0.

Lire ces conseils me donnent un peu l'impression de regarder l'intégralité de l'émission "Surprise sur prise". Je préfère encore Tiktok (regardé même pas 3 secondes dans ma vie).

C'est le traceur dans les liens ou le code en forme d'écureuil qui doit faire rire ?
- [^] # Re: 1 conseil pour donner des conseils
  
  Posté par gUI (Mastodon) le 23 février 2023 à 07:56. Évalué à 3.
  
  Où vois-tu encore des traceurs ? On va les enlever.
  
  En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# initialiser des variables s'il y a déjà des nuls

Posté par abriotde (site web personnel, Mastodon) le 23 février 2023 à 16:54. Évalué à 2.

Pourquoi initialiser des variables s'il y a déjà des nuls ?

J'avoue, ça m'est arrivé mais c'est piégeux. C'est comme utiliser 4/8 au lieu de sizeof()… En fait on est habitué à compiler avec toujours le même cvompilateur (g++) sur seulement des Linux X86 64 bits… Alors on a parfois tendances à faire quelques racourcis. C'est comme le coup du bigendian/littleendian.

Le problème se posera quand on voudra utiliser un autre OS/Compilateur/architecture.

Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
# Le pire c'est que ..

Posté par reno le 23 février 2023 à 17:19. Évalué à 7.

parfois j'ai vu des projets ou certains des "conseils" de la liste étaient appliqués!

Ma vie: j'arrive sur un projet pas petit, des dizaines de développeurs des milliers de ligne de code, on travaille à 2 sur une petite modification et ça core, il nous a fallu 1 journée pour trouver qu'il y avait un problème dans l'ordre d'initialisation des paramètres dans l'appel a un constructeur, on a trouvé le problème tout va bien. Sauf que le lendemain il y a un truc qui me tracasse: mais pourquoi le compilateur ne nous a pas prévenu??

La réponse, c'était [4] aucun warning activé dans le compilateur! Par curiosité, j'active les warnings et hop 600 warnings apparaissent. Là je vais voir mon chef: "on a un problème..".

Bon ayant participé au nettoyage, j'ai vu que sur les 600 warning juste 2 ou 3 étaient des vrais bugs, mais bon quel confort de développer avec les warnings activés!

Sinon 52: les struct c'est pénible: utiliser des entiers partout et fait des typedef pour définir des "types" pour les index, les id, des valeurs en octets ou en bits..
# Variables courtes

Posté par 2PetitsVerres le 28 février 2023 à 11:45. Évalué à 5.
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.

Pourtant c'est lisible. La preuve ce code (bon, normalement l'original est en FORTRAN, mais j'ai pas trouvé tout de suite) est utilisé depuis 42 ans, existe en 42 langages (avec les mêmes noms de variables, et la même absence de documentation, si on ignore le papier scientifique qui n'est plus à jour avec le code).

Cette utilisation sur le long terme et la traduction en plein de langages est bien la preuve que c'est la bonne façon d'écrire du code.

Au hasard, lisez la ligne 340. On comprend directement ce que c4 fait, et sa relation avec tsi, eeta et x1mth2 !
```
c4 = (real)2.0 * (real)xnodp * coef1 * aodp * betao2 * (eta *
     ((real)2.0 + (real)0.5 * etasq) + eo * ((real)0.5 + (real)2.0 *
     etasq) - (real)(2.0 * CK2) * tsi / (aodp * psisq) * ((real)-3.0 *
     x3thm1 * ((real)1.0 - (real)2.0 * eeta + etasq *
     ((real)1.5 - (real)0.5 * eeta)) + (real)0.75 * x1mth2 * ((real)2.0 *
     etasq - eeta * ((real)1.0 + etasq)) * COS((real)2.0 * omegao)));
```
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
# point 35 : plus partagé

Posté par Selso (site web personnel) le 24 mars 2023 à 10:01. Évalué à 3.

Pour le point 35 je suis plus partagé.
Tout déclarer en début de fonction c'est aussi une bonne métrique pour vérifier la complexité.
Si tu dépasses les 5 variables et qu'en plus certaines de celles-ci ont une utilisation éloignée dans le code, il faudrait penser à refactoriser.
On peut exclure les variables d'itération de cette considération et suivre le principe expliqué dans l'article d'origine.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.