Discussion :

[hegros]

Au contraire, je trouve la notation hongroise très utile, ça évite d'avoir à consulter systématiquement la documentation pour connaître le type des variables.
Pour une va

Avec un EDI qui fait du refactoring : clic droit>refactoring>type variable ou localisation definition l'affaire est réglée pas besoin d'ouvrir un autre programme ou se mettre à chercher les clés de l'armoire de documentation

Certe c'est une spécificité technique tout les langages n'ont pas un edi qui permet de le faire, la doc c'est lourd sauf en version light(web)

[Matthieu Brucher]

Au contraire, je trouve la notation hongroise très utile, ça évite d'avoir à consulter systématiquement la documentation pour connaître le type des variables.

Justement, c'est le problème. Les IDE actuels fournissent cette information sans problème. En revanche, en terme de maintenabilité, d'évolution ou de lecture, c'est une information parasite.

[Matthieu Brucher]

Certe c'est une spécificité technique tout les langages n'ont pas un edi qui permet de le faire.

En Python par exemple, ce serait une erreur de mettre le type de la variable, puisque grâce au typage dynamique, on peut utiliser une fonctiona vec un autre type que celui de départ. Dans ce cas, un IDE ne peut effectivement pas donner le type, mais en même temps, ce n'est pas pertinent.

[hegros]

Dans ce cas, un IDE ne peut effectivement pas donner le type, mais en même temps, ce n'est pas pertinent.

Cela le serait pour un script de test par exemple c'est donc un manque dans l'ide à mon goût.

[souviron34]

• utiliser la notation hongroise pour les noms de fonctions et de variables,

Au contraire, je trouve la notation hongroise très utile, ça évite d'avoir à consulter systématiquement la documentation pour connaître le type des variables.
Par ailleurs, si on change sans arrêt les liste en vecteurs, c'est qu'il y a un problème de conception.

La notation hongroise est une abomination... d'ailleurs issue dune erreur de traduction du gars ingénieur de chez Microsoft.. (confusion entre le mot "kind" et le mot "type" : ce qu'il voulait dire c'est préfixer par le type (dans le sens "kind", c'est à dire l'espèce, la sorte) de la variable et non le type (dans le sens "type", c'est à dire le type pour nous) de cette même variable : une chaîne en entrée/sortie n'est pas du même "kind" que une chaîne en entrée seul, bien qu'elles soient toutes les deux du "type" "chaîne".. Ce qu'il voulait donc qualifier c'est que c'était en entrée/sortie, en entrée, ou en sortie.. PAS QUE C'ETAIT UNE CHAINE)


Je l'ai (malheureusement) expérimenté à mes dépens il y a 2 ans sur un très gros projet..

A eviter absolument...

Et je ne suis pas le seul à le dire :

Même le site même de Microsoft (à propos de la MSDN) :

General Naming conventions

Do choose easily readable identifier names. For example, a property named HorizontalAlignment is more readable in English than AlignmentHorizontal.

Do favor readability over brevity. The property name CanScrollHorizontally is better than ScrollableX (an obscure reference to the X-axis).

Do not use underscores, hyphens, or any other nonalphanumeric characters.

Do not use Hungarian notation.
Hungarian notation is the practice of including a prefix in identifiers to encode some metadata about the parameter, such as the data type of the identifier.

Avoid using identifiers that conflict with keywords of widely used programming languages.

Hungarian notation : Good Idea ?

The change is that Microsoft no longer recommends Hungarian prefixes for variable names

Hungarian notation : the good, the bad, and the ugly

When the type of a variable changes, it is not likely that you are going to hunt through all the code and change all occurrences of its name. Especially during the schedule crunch. Thus, the variables name will become a lie.
..
For an example of this, look at the documentation for wParam in Microsoft Windows 32-bit: It changed from a 16-bit value (w stands for word) to a 32-bit value (which should have been dwParam). -YS]

hungarian notation is clearly goodbad

Notations that incorporate type information in variable names have mixed utility in type-unsafe languages (notably C), are possible but have no benefits (only drawbacks) in object-oriented languages, and are impossible in generic programming. Therefore, no C++ coding standard should require Hungarian notation, though a C++ coding standard might legitimately choose to ban it.

the compiler already knows much more than you do about an object’s type. Changing the variable’s name to embed type information adds little value and is in fact brittle. And if there ever was reason to use some Hungarian notation in C-style languages, which is debatable, there certainly remains no value when using type-safe languages.”

Making wrong code look wrong

Somebody, somewhere, read Simonyi’s paper, where he used the word “type,” and thought he meant type, like class, like in a type system, like the type checking that the compiler does. He did not. He explained very carefully exactly what he meant by the word “type,” but it didn’t help. The damage was done.

Apps Hungarian had very useful, meaningful prefixes like “ix” to mean an index into an array, “c” to mean a count, “d” to mean the difference between two numbers (for example “dx” meant “width”), and so forth

Systems Hungarian had far less useful prefixes like “l” for long and “ul” for “unsigned long” and “dw” for double word, which is, actually, uh, an unsigned long. In Systems Hungarian, the only thing that the prefix told you was the actual data type of the variable.

This was a subtle but complete misunderstanding of Simonyi’s intention and practice, and it just goes to show you that if you write convoluted, dense academic prose nobody will understand it and your ideas will be misinterpreted and then the misinterpreted ideas will be ridiculed even when they weren’t your ideas.

plus dans le très rigolo

How To Write Unmaintainable Code

Hungarian Notation
Hungarian Notation is the tactical nuclear weapon of source code obfuscation techniques; use it! Due to the sheer volume of source code contaminated by this idiom nothing can kill a maintenance engineer faster than a well planned Hungarian Notation attack. The following tips will help you corrupt the original intent of Hungarian Notation:
..
..
Insist on carrying outright orthogonal information in your Hungarian warts. Consider this real world example: "a_crszkvc30LastNameCol". It took a team of maintenance engineers nearly 3 days to figure out that this whopper variable name described a const, reference, function argument that was holding information from a database column of type Varchar[30] named "LastName" which was part of the table’s primary key. When properly combined with the principle that "all variables should be public" this technique has the power to render thousands of lines of source code obsolete instantly!
...

de PC Advisor :

11 old programming skills we can happily live without

Hungarian notation and other language limitations

BREF, NE JAMAIS UTILISER est un conseil sage...


En fait, la solution est simplement d'avoir des noms de variables clairs, et quand on le peut définir des classes bien nommées..

[hegros]

Moral de l'histoire : Commentez, commentez, commentez...

Le code est la documentation. Quand tu as écris 500000lignes de code en langageX tu ne penses pas que c'est suffisamment comme commentaire ?

Si tu as besoin de t'exprimer sur une fonction, un paramètre beh tu regardes dans le glossaire ou dans une documentation technique mais normalement un code 'propre' ne devrait pas nous amener à aller rechercher une information au fin fond de l'univers il est auto-documentant.


Moral de l'histoire :

plutôt que de prendre l'habitude de commentez systèmatiquement utilisez plutôt une feuille de brouillon pour vos commentaires persos et laissez le fichier code source que le minimum pour que le programme fonctionne.

[mayayu]

Le code est la documentation. Quand tu as écris 500000lignes de code en langageX tu ne penses pas que c'est suffisamment comme commentaire ?

Si tu as besoin de t'exprimer sur une fonction, un paramètre beh tu regardes dans le glossaire ou dans une documentation technique mais normalement un code 'propre' ne devrait pas nous amener à aller rechercher une information au fin fond de l'univers il est auto-documentant.


Moral de l'histoire :

plutôt que de prendre l'habitude de commentez systèmatiquement utilisez plutôt une feuille de brouillon pour vos commentaires persos et laissez le fichier code source que le minimum pour que le programme fonctionne.

Chaque développeur a sa façon de voir les choses; demandes à 2 personnes de te coder la même fonction (un peu complexe), il y aura des différences.
Imagines ce que ça donne sur une application entière.

En ce moment, j'en fais évoluer une (développée en C) que je n'ai pas écrite, elle n'est pas commentée, je ne connais pas le développeur...
Je suis obligé de partir du main et de remonter de fonctions en fonctions (et parfois de fichier en fichiers), jusqu'à trouver ce que je cherche.
Et ça, tout simplement parce que j'aurais pas du tout fait comme il/elle a fait, donc c'est le seul moyen que j'ai.
Petit à petit, on comprend la logique, mais que de temps perdu, quelques indications n'auraient pas été les malvenues...

P.S. 1 :Si tu éprouves le besoin d'avoir des commentaires perso, c'est certainement qu'ils seront aussi nécessaires à ceux qui passeront après toi.

P.S. 2 : Quand je parle de modifier le programme d'un autre, ça m'est déjà arrivé de reprendre mes propres développements quelques années plus tard.
J'ai évolué durant ce temps, et bien si je n'avais pas su que c'était moi qui l'avait écrit, je l'aurais pas deviné.
Les commentaires m'ont été bien utiles.

[Matthieu Brucher]

Chaque développeur a sa façon de voir les choses; demandes à 2 personnes de te coder la même fonction (un peu complexe), il y aura des différences.
Imagines ce que ça donne sur une application entière.

D'où l'intérêt d'un code propre. Le code lui-même doit être explicite. Commentaires ou pas, si ce n'est pas le cas, le commentaire est inutile (surtout s'il a été écrit après l'écriture du code).

[pseudocode]

Le code est la documentation.

Ca dépend ce que tu mets dans tes commentaire. Un commentaire ne doit pas expliquer ce que fait le code car cela doit normalement se déduire de la lecture du code (code "auto-documenté"). Un commentaire doit expliquer ce que le code ne dit pas : les raisons qui ont poussé a choisir ce code plutot qu'un autre.

Un petit exemple ?

Code original

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
r = n / 2;
while ( abs( r - (n/r) ) > t ) {
  r = 0.5 * ( r + (n/r) );
}

Code commenté

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
// square root of n with Newton-Raphson approximation
r = n / 2;
while ( abs( r - (n/r) ) > t ) {
  r = 0.5 * ( r + (n/r) );
}

code auto-documenté (par refactor)

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
private double SquareRootNewtonRaphsonApproximation(n) {
  r = n / 2;
  while ( abs( r - (n/r) ) > PRECISION ) {
    r = 0.5 * ( r + (n/r) );
  }
  return r;
}

code auto-documenté commenté

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
//  Math.sqrt() replacement using Newton-Raphson algorithm
private double SquareRoot(n) {
  r = n / 2;
  while ( abs( r - (n/r) ) > PRECISION ) {
    r = 0.5 * ( r + (n/r) );
  }
  return r;
}

[mayayu]

D'où l'intérêt d'un code propre. Le code lui-même doit être explicite. Commentaires ou pas, si ce n'est pas le cas, le commentaire est inutile (surtout s'il a été écrit après l'écriture du code).

Là je suis d'accord, il faut que le commentaire soit écrit lors du codage et qu'il soit pertinent, sinon ça sert à rien.

[Matthieu Brucher]

code auto-documenté commenté

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
//  Math.sqrt() replacement using Newton-Raphson algorithm
private double SquareRootApproximation(n) {
  r = n / 2;
  while ( abs( r - (n/r) ) > t ) {
    r = 0.5 * ( r + (n/r) );
  }
  return r;
}

Mais mal nommé, les variables ne sont pas assez explicites

Là je suis d'accord, il faut que le commentaire soit écrit lors du codage et qu'il soit pertinent, sinon ça sert à rien.

Pas lors du codage, avant.

[mayayu]

code auto-documenté commenté

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
// square root of n with Newton-Raphson approximation
r = n / 2;
while ( abs( r - (n/r) ) > t ) {
  r = 0.5 * ( r + (n/r) );
}

C'est un bon exemple.
Si on a pas le commentaire, il faudrait reprendre l'algorithme sur une feuille, chercher ce que ça peut bien être...
Avec le commentaire, on a tout ce qu'il nous faut!

[pseudocode]

Mais mal nommé, les variables ne sont pas assez explicites

Pas lors du codage, avant.

oui, j'ai été un peu vite.

j'ai corrigé.

[Matthieu Brucher]

oui, j'ai été un peu vite.

j'ai corrigé.

Et r et n ?

[mayayu]

Et r et n ?

C'est très clair "n" veut dire number, "r" result.
Je ne vois pas où est le problème

[Matthieu Brucher]

Ce n'est pas suffisamment pertinent. result n'est pas non plus l'idéal.

Si r signifie result, pourquoi ne pas le mettre directement ? A ce moment, ce ser vraiment explicite, on saura de quoi on parle.

result n'est pas idéal parce que ça n'apporte rien sur le déroulement de l'algorithme. approximated_root ou root serait des noms plus adaptés.

[koala01]

Salut,

Autant l'avouer, je n'ai lu que les trois premières pages de la discussion mais, selon moi:

Un code propre est, avant tout, facilement lisible et compréhensible par quiconque posant les yeux dessus (aller, rajoutons "et connaissant un minimum le langage"

Cela implique:

• des choix de noms de variables et de fonctions facilement compréhensibles
• une identation correcte
• des commentaires efficaces et utiles

Mais c'est aussi un code qui évite autant que faire se peut les "sucres syntaxiques" et les effets de bords...

[hegros]

Ca dépend ce que tu mets dans tes commentaire.

Pour ma part les commentaires se limiteraient à une entête du fichier, une cartouche pas de plus.

Un commentaire doit expliquer ce que le code ne dit pas : les raisons qui ont poussé a choisir ce code plutot qu'un autre.

Nous sommes d'accord qu'il faut bien un commentaire pour expliquer les raisons et choix techniques. Cependant pourquoi le faire dans le code source ? Si c'est un choix d'architecture l'architecte devrait en avoir connaissance sans à avoir à ouvrir le fichier source de même que le testeur ou le...


Le code source est un document de programmation. Les choix et raisons technniques est un document de conception logiciel (sur un wiki?). Là ce que tu nous proposes c'est une solution documentaire 2 en 1 ?

[Matthieu Brucher]

Le code source est un document de programmation. Les choix et raisons technniques est un document de conception logiciel (sur un wiki?). Là ce que tu nous proposes c'est une solution documentaire 2 en 1 ?

Complètement d'accord, il s'agit plus des spécifications que du code dans ce cas.

[pseudocode]

Ce n'est pas suffisamment pertinent. result n'est pas non plus l'idéal.

Si r signifie result, pourquoi ne pas le mettre directement ? A ce moment, ce ser vraiment explicite, on saura de quoi on parle.

result n'est pas idéal parce que ça n'apporte rien sur le déroulement de l'algorithme. approximated_root ou root serait des noms plus adaptés.

Non, justement. Le commentaire a pour but d'expliquer ce que l'auto-documentation du code n'explique pas.

L'auto-documentation doit s'arrêter a ce qui est utile pour l'utilisateur du code ( celui qui va appeler la fonction ). Ici l'auto-documentation (= le nommage) explique que la fonction calcule une racine carré. C'est tout ce que l'appelant a besoin de savoir.

Pour avoir plus d'informations, il y a le commentaire : on utilise l'algo de Newton-Raphson. Cette information n'est pas primordiale pour utiliser la fonction, mais elle l'est pour comprendre comment elle fonctionne.