Posté par jseb .
Évalué à 2.
Dernière modification le 23 décembre 2022 à 10:11.
bien entendu, il fallait lire « bonneS pratiques ».
Mon doigt a validé, ignorant les protestations de la masse grise un peu inutile sur ce coup. Cette même masse grise me contraint à écrire ce message marri.
Discussions en français sur la création de jeux videos : IRC freenode / #gamedev-fr
Notamment le point 9.4 et 9.5. Les FAM peuvent être risqués mais les union sont particulièrement pratiques, les interdire complètement est un peu rigide.
L'annexe E est extrêmement subjective.
Une fonction de 500 lignes c'est beaucoup trop et j'en ai rarement vu dans des projets propres.
E4.5, non, on ne doit pas faire des types maison en _t. C'est réservé par POSIX.
E4.7, pitié la notation hongroise doit disparaitre.
git is great because linus did it, mercurial is better because he didn't
les union sont particulièrement pratiques, les interdire complètement est un peu rigide.
Ce n'est pas interdit complètement justement:
L’utilisation des unions doit strictement être limitée à des cas où le type est vérifié par un autre moyen et que si cela est nécessaire (pour le parsing de trame réseau par exemple) et cela devra être justifié en commentaire dans le code.
Donc on ne parle pas d'interdiction complète mais plutôt à éviter en première approche.
L'annexe E est extrêmement subjective.
Et c'est écrit au début:
Les points suivants proposent un exemple de conventions de codage. Certains choix
sont arbitraires et discutables.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Perso je me demande surtout comment on peut avoir eu l'idée.
Un nom donne une indication sur ce que ça fait, le type se déduit avec un IDE digne de ce nom en passant le curseur sur le nom et il y a un avertissement si la variable est "mal" utilisée.
Peut-être qu'au début de l'informatique on n'avait pas d'IDE et que du coup ça avait un minimum de sens à défaut d'être bien, mais alors aujourd'hui la question est plutôt pour toi, pourquoi elle ne devrait pas disparaître?
Du coup, oui, "arbitraires et discutables", largement. Et que ce soit dans cette doc n'est pas terrible, ça peut donner l'idée que si les auteurs sont un peu bizarres et qu'il faudrait prendre le reste du doc avec de grosses pincettes, du moins un esprit très critique dessus, mélanger les genres n'aident pas à diffuser.
Posté par Meku (site web personnel) .
Évalué à 3.
Dernière modification le 25 décembre 2022 à 13:24.
Comme l'a dit Zenitram, les outils modernes sont capables de nous rappeler le type des variables avec des codes couleurs ou info-bulles.
Il y a aussi les bonnes pratiques de programmation qui permettent de s'en affranchir : pour les variables locales, leur déclaration sont généralement visibles à l'écran si on n'écrit pas des fonctions de 500 lignes difficiles à lire.
À la place de la notation hongroise où l'ont indique le type informatique d'une variable, il est plus pertinent (notamment pour les langages faiblement typés comme le C) d'indiquer l'unité de mesure de la variable.
J'ai bossé sur un projet où on devait s'interfacer avec le client. L'interface en IDL était totalement en notation hongroise, avec des variables de ce style :
float m_fDistance;
Sauf que ça me fait une belle jambe de savoir en lisant « m_fDistance » que c'est un float et une variable membre de la structure qui le contient, ça mes outils savent me l'indiquer sans problème, par contre ce que je ne sais pas, c'est en quoi est exprimée cette distance ? En mètres ? En miles ? Bref, vu que l'interface était exprimée en langage IDL, j'aurais préféré avoir quelque chose comme :
Sauf que ça me fait une belle jambe de savoir en lisant « m_fDistance » que c'est un float et une variable membre de la structure qui le contient
Autant je suis d'accord qu'indiquer le type (int, float, char, str…) dans le nom est peu utile (voire est une gêne), autant je trouve qu'avoir des conventions qui permettent de connaître la portée d'une variable est utile, ça permets d'éviter d'avoir plusieurs variables donc le label est strictement identique, ce qui peut arriver quand on utilise des variables non-locales (extern ou static, peu importe).
Les IDE sont capables de mettre une couleur différente selon si c'est une variable locale, membre, globale, etc. Peut-être pas les éditeurs qui font coloration syntaxique mais sans plus.
Ca doit faire un sacré sapin de noel à la fin, pas sûr que d'avoir autant de couleurs soit une bonne idée (au bout d'un moment, ça appelle la confusion entre couleurs, non?).
Personnellement, je préfère régler mon compilateur pour actionner le maximum de warning et les corriger, hors, le cas des shadow variables déclenche un warning. Je n'utilise également pas d'IDE, ce qui me permets d'éditer le code de n'importe quel logiciel sur mon PC en un temps record (tous les IDE que j'ai utilisés par le passé, probablement pas loin d'une dizaine, étaient lents à se lancer comparé à vim. Je n'ai jamais utilisé emacs, je ne sais donc pas pour cet OS, mais j'ai lu que son éditeur de code était pas génial).
Il y a aussi le cas des revues de code, notamment via l'outil de github, qui à ma connaissance ne supporte pas ce genre de fonctionnalité.
Bon, après, je suppose que c'est une question de goût.
Au passage, par curiosité je viens d'aller revoir rapidement la page de wikipedia sur cette notation. Du coup, je suis en désaccord avec tous ceux qui veulent sa suppression, parce que:
Hungarian notation is an identifier naming convention in computer programming, in which the name of a variable or function indicates its intention or kind, and in some dialects its type. The original Hungarian notation uses intention or kind in its naming convention
Autrement dit, le but n'est pas seulement en rapport avec le type mais avec l'intention ou le type. Quant à la portée, elle est gérée initialement via la casse du 1er caractère non lié à la notation (given name comme ils disent).
Je note ici que l'article utilise le terme "kind" et non "type", ce qui est "expliqué" peu après:
As the Microsoft Windows division adopted the naming convention, they used the actual data type for naming, and this convention became widely spread through the Windows API; this is sometimes called Systems Hungarian notation.
En fait, ajouter le type (int, float, pointer, …) dans le nommage n'est pas la notation hongroise, mais la notation hongroise système (je l'apprend, perso, comme quoi ça fait pas de mal d'aller fouiller parfois).
Exemples que j'ai trouvés pertinents dans la page wikipedia:
Apps Hungarian notation strives to encode the logical data type rather than the physical data type; in this way, it gives a hint as to what the variable's purpose is, or what it represents.
rwPosition : variable represents a row ("rw");
usName : variable represents an unsafe string ("us"), which needs to be "sanitized" before it is used (e.g. see code injection and cross-site scripting for examples of attacks that can be caused by using raw user input)
szName : variable is a zero-terminated string ("sz"); this was one of Simonyi's original suggested prefixes.
Je ne doute pas qu'un outil d'analyse statique soit capable de détecter ce type d'information, mais je trouve personnellement la méthode de la notation hongroise bien plus simple et plus élégante que de faire des distinguo par couleur et autres. Et l'analyse statique, ça a un coût, tout le monde n'a pas une bête de course pour coder, notamment parce que ce n'est pas souvent si utile que ça (et pourtant je code en C++ hein), sauf pour des gros projets qui embarquent énormément de dépendances complexes dans chaque unité de compilation (utilisateurs de boost, je vous regarde).
Dans la liste des avantages défendus par ceux qui en sont adeptes, on retrouve d'ailleurs quelques-uns de ceux que j'ai cités: la lisibilité du code en dehors d'un IDE ("This is useful when looking at the code outside an integrated development environment — like on a code review or printout" j'avoue ne pas avoir osé parler d'imprimer le code, mais j'y avais bel et bien pensé, ça m'arrive de temps en temps d'utiliser le papier, même si c'est super rare), ainsi que le problème de la collision des noms ("Applying Hungarian notation in a narrower way, such as applying only for member variables, helps avoid naming collision").
Au final, on pourrait dire qu'utiliser par exemple "mDistance" pour distance en mètres (ou mt pour meters, je sais pas. Le problème après c'est d'établir une convention quand ça à un intérêt de par l'usage assez répandu, sinon on ajoute juste des emmerdes), c'est de la notation hongroise, et il me semble avoir lu que c'est quelque chose qui manque souvent ;)
À la place de la notation hongroise où l'ont indique le type informatique d'une variable, il est plus pertinent (notamment pour les langages faiblement typés comme le C) d'indiquer l'unité de mesure de la variable.
Bravo, vous réinventez la notation hongroise, façon µs (ou IDL chez vous), pour faire tout le contraire… Aussi loin que je me souvienne, il ne s’agit pas d’indiquer le typage (sauf quelques rares cas)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Aussi loin que je me souvienne, il ne s’agit pas d’indiquer le typage (sauf quelques rares cas)
Déjà lu ça une fois, que la notation hongroise a été mal comprise, etc.
Le problème c'est qu'en pratique, elle a largement été mal comprise chez tout le monde. Partout où je l'ai vu appliquée c'était pour le typage. Donc à la fin, si tout le monde l’interprète pareil, la notion change de définition dans le langage courant…
Parce que ça n'apporte rien à partir du moment où une variable est bien nommée. Si un jour tu écris mapPlayers car ton type de données est une map. Ok. Tu commences à la référencer à plein d'endroits et le jour où tu changes de type tu dois renommer la variable à plein d'endroits. Oui on peut faire un rechercher remplacer mais ça reste une opération inutile d'autant plus que tu introduis des possibles merge-conflicts.
Si je lis une variable delay je me doute que ce sera probablement un nombre. Si je lis clients je me doute que ce sera probablement une collection de clients.
git is great because linus did it, mercurial is better because he didn't
Si je lis clients je me doute que ce sera probablement une collection de clients.
Tu sais s'ils sont triés et si oui par quoi, dédoublonnés, si l'ordre a un sens ou non,… ?
Je ne fais pas du C, mais je trouve personnellement que la démarcation que tu fais peut être bien plus flou que ça et que bien souvent les types du langages ne permettent pas forcément d'exprimer ce que tu entends par type. C'est donc une information que tu te retrouve à :
soit ne la mettre nul part et au développeur de la redéduire. C'est souvent fait pour des variables local qui sont utilisé sur de toutes petites portions de code
soit tu la met dans le nom de la variable d'une façon ou d'une autre
soit tu la met dans les commentaires avec certaines conventions ça peut être utilisé par les outils pour ne pas avoir à naviguer dans le code pour les lire
Je ne vois pas de solution particulièrement magique qui me ferrait dire qu'une solution est hors contexte meilleure que les autres.
Posté par nico4nicolas .
Évalué à 4.
Dernière modification le 23 décembre 2022 à 12:48.
Lors de précédentes versions, desliens étaient déjà parus ici même.
Ce document me semble très bien fait, bien pensé avec un bon exemple et un mauvais. Il y a aussi des références aux règles sur lesquelles s'appuie chaque bonne pratique/recommandation/règle pour justifier que ce n'est pas sorti de nulle part. Bravo à l'ANSSI.
# communication du machin d'en haut dans ma tête
Posté par jseb . Évalué à 2. Dernière modification le 23 décembre 2022 à 10:11.
bien entendu, il fallait lire « bonneS pratiques ».
Mon doigt a validé, ignorant les protestations de la masse grise un peu inutile sur ce coup. Cette même masse grise me contraint à écrire ce message marri.
Discussions en français sur la création de jeux videos : IRC freenode / #gamedev-fr
[^] # Re: communication du machin d'en haut dans ma tête
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
# Pas d'accord avec tout
Posté par David Demelier (site web personnel) . Évalué à 3.
Notamment le point 9.4 et 9.5. Les FAM peuvent être risqués mais les
unionsont particulièrement pratiques, les interdire complètement est un peu rigide.L'annexe E est extrêmement subjective.
_t. C'est réservé par POSIX.git is great because linus did it, mercurial is better because he didn't
[^] # Re: Pas d'accord avec tout
Posté par claudex . Évalué à 7.
Ce n'est pas interdit complètement justement:
Donc on ne parle pas d'interdiction complète mais plutôt à éviter en première approche.
Et c'est écrit au début:
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pas d'accord avec tout
Posté par Ambroise . Évalué à 4.
Par curiosité, pourquoi ? C'est un avis subjectif ou il y a de vrais raisons connues ?
[^] # Re: Pas d'accord avec tout
Posté par Zenitram (site web personnel) . Évalué à 3.
Perso je me demande surtout comment on peut avoir eu l'idée.
Un nom donne une indication sur ce que ça fait, le type se déduit avec un IDE digne de ce nom en passant le curseur sur le nom et il y a un avertissement si la variable est "mal" utilisée.
Peut-être qu'au début de l'informatique on n'avait pas d'IDE et que du coup ça avait un minimum de sens à défaut d'être bien, mais alors aujourd'hui la question est plutôt pour toi, pourquoi elle ne devrait pas disparaître?
Du coup, oui, "arbitraires et discutables", largement. Et que ce soit dans cette doc n'est pas terrible, ça peut donner l'idée que si les auteurs sont un peu bizarres et qu'il faudrait prendre le reste du doc avec de grosses pincettes, du moins un esprit très critique dessus, mélanger les genres n'aident pas à diffuser.
[^] # Re: Pas d'accord avec tout
Posté par Meku (site web personnel) . Évalué à 3. Dernière modification le 25 décembre 2022 à 13:24.
Comme l'a dit Zenitram, les outils modernes sont capables de nous rappeler le type des variables avec des codes couleurs ou info-bulles.
Il y a aussi les bonnes pratiques de programmation qui permettent de s'en affranchir : pour les variables locales, leur déclaration sont généralement visibles à l'écran si on n'écrit pas des fonctions de 500 lignes difficiles à lire.
À la place de la notation hongroise où l'ont indique le type informatique d'une variable, il est plus pertinent (notamment pour les langages faiblement typés comme le C) d'indiquer l'unité de mesure de la variable.
J'ai bossé sur un projet où on devait s'interfacer avec le client. L'interface en IDL était totalement en notation hongroise, avec des variables de ce style :
float m_fDistance;Sauf que ça me fait une belle jambe de savoir en lisant « m_fDistance » que c'est un float et une variable membre de la structure qui le contient, ça mes outils savent me l'indiquer sans problème, par contre ce que je ne sais pas, c'est en quoi est exprimée cette distance ? En mètres ? En miles ? Bref, vu que l'interface était exprimée en langage IDL, j'aurais préféré avoir quelque chose comme :
float distanceMeters;[^] # Re: Pas d'accord avec tout
Posté par barmic 🦦 . Évalué à 2.
Dans les bons langages tu écrira simplement :
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pas d'accord avec tout
Posté par Meku (site web personnel) . Évalué à 2.
Oui, c'est encore mieux si on peut écrire ça.
[^] # Re: Pas d'accord avec tout
Posté par freem . Évalué à 3.
Autant je suis d'accord qu'indiquer le type (int, float, char, str…) dans le nom est peu utile (voire est une gêne), autant je trouve qu'avoir des conventions qui permettent de connaître la portée d'une variable est utile, ça permets d'éviter d'avoir plusieurs variables donc le label est strictement identique, ce qui peut arriver quand on utilise des variables non-locales (extern ou static, peu importe).
[^] # Re: Pas d'accord avec tout
Posté par Meku (site web personnel) . Évalué à 3.
Les IDE sont capables de mettre une couleur différente selon si c'est une variable locale, membre, globale, etc. Peut-être pas les éditeurs qui font coloration syntaxique mais sans plus.
[^] # Re: Pas d'accord avec tout
Posté par freem . Évalué à 3.
Ca doit faire un sacré sapin de noel à la fin, pas sûr que d'avoir autant de couleurs soit une bonne idée (au bout d'un moment, ça appelle la confusion entre couleurs, non?).
Personnellement, je préfère régler mon compilateur pour actionner le maximum de warning et les corriger, hors, le cas des shadow variables déclenche un warning. Je n'utilise également pas d'IDE, ce qui me permets d'éditer le code de n'importe quel logiciel sur mon PC en un temps record (tous les IDE que j'ai utilisés par le passé, probablement pas loin d'une dizaine, étaient lents à se lancer comparé à vim. Je n'ai jamais utilisé emacs, je ne sais donc pas pour cet OS, mais j'ai lu que son éditeur de code était pas génial).
Il y a aussi le cas des revues de code, notamment via l'outil de github, qui à ma connaissance ne supporte pas ce genre de fonctionnalité.
Bon, après, je suppose que c'est une question de goût.
Au passage, par curiosité je viens d'aller revoir rapidement la page de wikipedia sur cette notation. Du coup, je suis en désaccord avec tous ceux qui veulent sa suppression, parce que:
Autrement dit, le but n'est pas seulement en rapport avec le type mais avec l'intention ou le type. Quant à la portée, elle est gérée initialement via la casse du 1er caractère non lié à la notation (given name comme ils disent).
Je note ici que l'article utilise le terme "kind" et non "type", ce qui est "expliqué" peu après:
En fait, ajouter le type (int, float, pointer, …) dans le nommage n'est pas la notation hongroise, mais la notation hongroise système (je l'apprend, perso, comme quoi ça fait pas de mal d'aller fouiller parfois).
Exemples que j'ai trouvés pertinents dans la page wikipedia:
Je ne doute pas qu'un outil d'analyse statique soit capable de détecter ce type d'information, mais je trouve personnellement la méthode de la notation hongroise bien plus simple et plus élégante que de faire des distinguo par couleur et autres. Et l'analyse statique, ça a un coût, tout le monde n'a pas une bête de course pour coder, notamment parce que ce n'est pas souvent si utile que ça (et pourtant je code en C++ hein), sauf pour des gros projets qui embarquent énormément de dépendances complexes dans chaque unité de compilation (utilisateurs de boost, je vous regarde).
Dans la liste des avantages défendus par ceux qui en sont adeptes, on retrouve d'ailleurs quelques-uns de ceux que j'ai cités: la lisibilité du code en dehors d'un IDE ("This is useful when looking at the code outside an integrated development environment — like on a code review or printout" j'avoue ne pas avoir osé parler d'imprimer le code, mais j'y avais bel et bien pensé, ça m'arrive de temps en temps d'utiliser le papier, même si c'est super rare), ainsi que le problème de la collision des noms ("Applying Hungarian notation in a narrower way, such as applying only for member variables, helps avoid naming collision").
Au final, on pourrait dire qu'utiliser par exemple "mDistance" pour distance en mètres (ou mt pour meters, je sais pas. Le problème après c'est d'établir une convention quand ça à un intérêt de par l'usage assez répandu, sinon on ajoute juste des emmerdes), c'est de la notation hongroise, et il me semble avoir lu que c'est quelque chose qui manque souvent ;)
[^] # Re: Pas d'accord avec tout
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Bravo, vous réinventez la notation hongroise, façon µs (ou IDL chez vous), pour faire tout le contraire… Aussi loin que je me souvienne, il ne s’agit pas d’indiquer le typage (sauf quelques rares cas)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Pas d'accord avec tout
Posté par Meku (site web personnel) . Évalué à 3.
Déjà lu ça une fois, que la notation hongroise a été mal comprise, etc.
Le problème c'est qu'en pratique, elle a largement été mal comprise chez tout le monde. Partout où je l'ai vu appliquée c'était pour le typage. Donc à la fin, si tout le monde l’interprète pareil, la notion change de définition dans le langage courant…
[^] # Re: Pas d'accord avec tout
Posté par David Demelier (site web personnel) . Évalué à 1.
Parce que ça n'apporte rien à partir du moment où une variable est bien nommée. Si un jour tu écris
mapPlayerscar ton type de données est une map. Ok. Tu commences à la référencer à plein d'endroits et le jour où tu changes de type tu dois renommer la variable à plein d'endroits. Oui on peut faire un rechercher remplacer mais ça reste une opération inutile d'autant plus que tu introduis des possibles merge-conflicts.Si je lis une variable
delayje me doute que ce sera probablement un nombre. Si je lisclientsje me doute que ce sera probablement une collection de clients.git is great because linus did it, mercurial is better because he didn't
[^] # Re: Pas d'accord avec tout
Posté par barmic 🦦 . Évalué à -1.
Tu sais s'ils sont triés et si oui par quoi, dédoublonnés, si l'ordre a un sens ou non,… ?
Je ne fais pas du C, mais je trouve personnellement que la démarcation que tu fais peut être bien plus flou que ça et que bien souvent les types du langages ne permettent pas forcément d'exprimer ce que tu entends par type. C'est donc une information que tu te retrouve à :
Je ne vois pas de solution particulièrement magique qui me ferrait dire qu'une solution est hors contexte meilleure que les autres.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Les liens vers les liens des précédentes versions
Posté par nico4nicolas . Évalué à 4. Dernière modification le 23 décembre 2022 à 12:48.
Lors de précédentes versions, des liens étaient déjà parus ici même.
Ce document me semble très bien fait, bien pensé avec un bon exemple et un mauvais. Il y a aussi des références aux règles sur lesquelles s'appuie chaque bonne pratique/recommandation/règle pour justifier que ce n'est pas sorti de nulle part. Bravo à l'ANSSI.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.