Discussion :

[souviron34]

oui et c'est justement quasiment un contre-exemple à ne pas suivre...

[Matthieu Brucher]

Ton exemple va même au delà du simple problème de nommage, car dans le second cas tu fais intervenir de la surcharge de méthode. Surcharger une méthode engendre un coût de résolution (lookup) de la méthode à appeler, qui n'existe pas dans la première solution. Du coup, le second code est-il réellement plus "propre" ?

??? Ca dépend des langages sans doute, parce que la résolution est généralement statique, et donc le surcoût est... nul.

oui et c'est justement quasiment un contre-exemple à ne pas suivre...

On va dire que ça ne s'applique pas aux langages qui ne permettent pas al surcharge. Autrement, ça ne change strictement rien dans les langages où la performance est importante.

[souviron34]

Disons que je distingue simplement les différents documents qui puissent exister dans un projet tu ne peux pas tout mettre dans le code de même que la génération automatique de documentation (c'est un des seuls interet à écrire un commentaire de code) n'est pas la seule solution d'organisation documentaire !


Le commentaire de l'algo de sort en java me sert complétement à rien mais franchement c'est chiant tout ces octets gaspillés.

Dans 90% des projets les programmeurs qui documentent ne savent pas le faire aussi bien que pseudocode par exemple moi même y compris.

Pour te répondre souviron, oui j'ai affaire à ce genre de chose tout le temps et à chaque fois les commentaires de code ne me serve à rien sur un projet ou l'autre (je ne parle pas de démonstration ou tutoriaux par exemple mais de production)

Plutot que de devoir faire du code source un fourre tout documentaire je serais plus partisan d'utiliser un outil de rétro-ingénierie de code et d'annotez à guise puis de documenter

disons que justement un des problèmes majeurs de bons - longs projets en informatique c'est que tu n'as plus les documents (aucun). Ou, bien que tu ne sais pas si tu peux t'y fier (documents datant de quelques à qualques dizaines d'années, avec une longue histoire de modification depuis).

J'aimerais bien voir (ce que je n'ai pas encore vu) un outil de rétro-ingéniérie correct pour un gros projet complexe...


Je n'affirme rien, je parle juste par expérience..

Je dis juste qu'il est essentiel d'avoir de bons commentaires (comme on l'a spécifié plus haut) dans le code, de différentes natures à différents endroits (documenter le code, documenter le but et les entrées/sorties de la fonction, documenter son algo et sa source, documenter le but global du module, etc etc).

Ceux qui ne le font pas préparent des maux de tête carabinés à leurs successeurs, et ceux qui ne le font pas du tout indiquent simplement que l'on mettra leur code à la poubelle dans le futur..

[souviron34]

On va dire que ça ne s'applique pas aux langages qui ne permettent pas al surcharge. Autrement, ça ne change strictement rien dans les langages où la performance est importante.

admettons..

Mais encore une fois, cela nécessite un bon commentaire en tête, alors...

Car du point de vue d'une spec, on se doit d'être indépendant du langage..

[benji_dv]

Concernant le code à plusieurs return ...

c'est une question de point de vue,

Je pense que faciliter la lisibilité n'est pas un principe d'unicité de caractéristique,
au contraire, la complexité nait par le cumul d'un non respect de plusieurs règles :
plusieurs return, dans une fonction qui n'excède pas une 50 aine de lignes, et où le nombre de if imbriqué n'implique pas des conditions complexes, ne pose pas problème,
d'un autre côté, lorsque j'audite du code (ce qui m'arrive fréquemment) de nombreuses cause d'inlisibilité et donc d'erreur proviennent d'une combinaison de ces éléments là.

Car à tout moment, une personne reprenant un code pondu ya un moment va swapper un return et devra y mettre plus que du sien pour pouvoir comprendre la fonction.

Après tout dépends du contexte...

[Matthieu Brucher]

admettons..

Mais encore une fois, cela nécessite un bon commentaire en tête, alors...

Car du point de vue d'une spec, on se doit d'être indépendant du langage..

Dans la théorie. En pratique, on va toujours se placer dans le cas concret où on travaille. La surcharge est un outil utile.

Concernant le code à plusieurs return ...

c'est une question de point de vue,

Je pense que faciliter la lisibilité n'est pas un principe d'unicité de caractéristique,
au contraire, la complexité nait par le cumul d'un non respect de plusieurs règles :
plusieurs return, dans une fonction qui n'excède pas une 50 aine de lignes, et où le nombre de if imbriqué n'implique pas des conditions complexes, ne pose pas problème,
d'un autre côté, lorsque j'audite du code (ce qui m'arrive fréquemment) de nombreuses cause d'inlisibilité et donc d'erreur proviennent d'une combinaison de ces éléments là.

Car à tout moment, une personne reprenant un code pondu ya un moment va swapper un return et devra y mettre plus que du sien pour pouvoir comprendre la fonction.

Après tout dépends du contexte...

50 lignes, des boucles if imbriquées -> c'est un bon candidat au refactoring.
Ce qui est certain, c'est que c'est plus difficile de lire, pour moi, un code qui oblige à avoir un seul return (parce qu'en général, il y a aussi tropd e lignes de code, je pense notamment à l'implémentation C de JXTA qui est une horreur à ce niveau).

[DranDane]

Ton exemple va même au delà du simple problème de nommage, car dans le second cas tu fais intervenir de la surcharge de méthode. Surcharger une méthode engendre un coût de résolution (lookup) de la méthode à appeler, qui n'existe pas dans la première solution. Du coup, le second code est-il réellement plus "propre" ?

Ca se voit, non ? Tu trouves pas ? Le code est plus propre oui. Aussi performant j'en sais rien mais plus propre sans aucun doute.

oui et c'est justement quasiment un contre-exemple à ne pas suivre...

Ca m'intéresserais d'en savoir plus. Sur quel base dites vous cela. Avez-vous vérifié par vous même ou est ce encore un de ces nombreux mythes de performances ?

De toute façon peut importe. Programmer proprement ne va pas toujours dans le sens des performances. Au contraire, pour des questions de performance parfois on se permet un court circuit, une astuce, quelques chose d'un peu moins propre mais nettement plus efficace. Je dit pas que c'est bien, ni mal, juste que c'est moins propre.

Pour moi bien programmer, programmer proprement c'est avant tout programmer objet. L'objet c'est la surcharge des méthodes entre autre. Si c'est pour ne pas l'utiliser alors c'est que vous vous trompez de langage.

Ou alors on peut brûler tout les livres d'apprentissages...

[white_tentacle]

Pour reprendre l'exemple utilisé plus tôt :

Code :

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;
}

À corriger en :

Code :

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

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

S'il n'y a pas ces informations (en particulier, la précondition), le code ne saurait être qualifié de "propre". On ne sait même pas comment l'utiliser correctement sans rentrer dans le détail de l'implémentation.

[el_slapper]

(.../...) Programmer proprement ne va pas toujours dans le sens des performances. (.../...)

Amen.

exemple cobol(mais que tout le monde comprendra j'espère.....y'a que des booléens)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
IF PAIEMENT-A AND TIP-AUTORISE 
   SET COURRIER-TIP TO TRUE
ELSE
  IF PAIEMENT-B
      SET COURRIER-PRELEVEMENT-AGENT TO TRUE
   ELSE
      IF PAIEMENT-C
         SET COURRIER-PRELEVEMENT-SIEGE TO TRUE
      ELSE
         SET COURRIER-CHEQUE TO TRUE
      END-IF
   END-IF
END-IF

sera 2 fois plus rapide, environ, que

Code :

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

1
2
3
4
5
6
7
8
9
10
11
EVALUATE TRUE
   WHEN PAIEMENT-A AND TIP-AUTORISE 
      SET COURRIER-TIP TO TRUE
   WHEN PAIEMENT-B
      SET COURRIER-PRELEVEMENT-AGENT  TO TRUE
   WHEN PAIEMENT-C
      SET COURRIER-PRELEVEMENT-SIEGE TO TRUE
   WHEN OTHER
      SET COURRIER-CHEQUE TO TRUE
END-EVALUATE

Pourtant, c'est la seconde solution que j'ai choisie - avec l'assentiment de ma hiérarchie(on a pas mal discuté de cet aiguillage, y'avait des conséquences un peu partout(et puis j'ai simplifié la condition réelle)).

Cette solution a surtout l'avantage de se lire exactement comme la spécification :
==>si c'est un paiement TIP et que celui-ci est autorisé, alors on fait un courrier TIP
==>Si c'est un prélevement agent.....(blablabla)
(.../...)
==>dans tous les autres cas, on envoie le courrier "chèque"

le jour ou la spec change(genre on crée un nouveau courrier pour les gens qui devaient payer par TIP mais n'y sont pas autorisés), le premier code devient illisible, avec une imbrication de plus, alors que le second, y'a juste à rajouter

Code :

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

1
2
3
   WHEN PAIEMENT-A AND NOT TIP-AUTORISE 
      SET COURRIER-TIP-ALTERNATIF TO TRUE

Et ça reste parfaitement lisible(enfin, à mon sens, peut-être certains ici auront des remarque astucieuses à faire).

[Franck SORIANO]

disons que justement un des problèmes majeurs de bons - longs projets en informatique c'est que tu n'as plus les documents (aucun). Ou, bien que tu ne sais pas si tu peux t'y fier (documents datant de quelques à qualques dizaines d'années, avec une longue histoire de modification depuis).

Je dis juste qu'il est essentiel d'avoir de bons commentaires (comme on l'a spécifié plus haut) dans le code,

C'est vrai que sur une doc qui a un peu vécu, il arrive un moment où on ne sait plus si la doc est fiable (surtout si le code semble faire autre chose que la doc).

J'ajouterais également, que malheureusement, c'est la même chose avec les commentaires dans le code. Dès que le code a un peu vécu, tu finis aussi par te demander si les commentaires sont encore fiables.

[white_tentacle]

Et ça reste parfaitement lisible(enfin, à mon sens, peut-être certains ici auront des remarque astucieuses à faire).

Tu as des états vraisemblablements exclusifs dans ton code (à priori, on aurait soit PAIEMENT_A, soit PAIEMENT_B, mais jamais les deux à la fois) mais ça ne se voit pas clairement, il n'y a aucun moyen d'en être sûr.

Le choix d'utiliser des booléens est donc mauvais à mon sens, une énumération aurait sûrement été préférable (après, je ne connais pas Cobol, peut-être n'est-ce pas possible).

[Gtrwld]

Ton exemple va même au delà du simple problème de nommage, car dans le second cas tu fais intervenir de la surcharge de méthode. Surcharger une méthode engendre un coût de résolution (lookup) de la méthode à appeler, qui n'existe pas dans la première solution. Du coup, le second code est-il réellement plus "propre" ?

Sauf erreur de ma part, il y a un coût de résolution des méthodes uniquement à la compilation, deux surcharges d'une méthode étant considérées comme des méthodes différentes par la suite. Ce qui n'est pas très gênant à mon avis.

En C#:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
static void Main()
{
	GetUserData(0);
	GetUserData("name");
}
private static string GetUserData(string name)
{
	return "data by name";
}
private static string GetUserData(int ID)
{
	return "data by ID";
}

En MSIL:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
.method private hidebysig static void Main() cil managed
{
    .entrypoint
    .maxstack 8
    L_0000: nop 
    L_0001: ldc.i4.0 
    L_0002: call string ConsoleApplication1.Program::GetUserData(int32)
    L_0007: pop 
    L_0008: ldstr "name"
    L_000d: call string ConsoleApplication1.Program::GetUserData(string)
    L_0012: pop 
    L_0013: ret 
}

En assembleur:

Code :

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

1
2
3
4
5
6
7
8
    GetUserData(0);
00000022  xor         ecx,ecx 
00000024  call        FD2FB000
00000029  nop              
    GetUserData("name");
0000002a  mov         ecx,dword ptr ds:[02292088h] 
00000030  call        FD2FAFF8
00000035  nop

Method invocations sur MSDN:
http://msdn.microsoft.com/en-us/libr...56(VS.71).aspx

[hegros]

Je dis juste qu'il est essentiel d'avoir de bons commentaires (comme on l'a spécifié plus haut) dans le code, de différentes natures à différents endroits (documenter le code, documenter le but et les entrées/sorties de la fonction, documenter son algo et sa source, documenter le but global du module, etc etc).

Tu te rends compte de ce que tu dis ? documenter un algo dans le code source c'est parfait pour un tutoriel ou un livre (pour apprendre)pour rendre plus dense, un éditeur de code n'est pas ce qu'il y a de mieux pour documenter.

Aussi, j'ai écris des programmes où chaque caractère d'un commentaire compte comme un octet. Le programme n'est pas chargé en mémoire vive puisque c'est embarqué sur du matériel électronique et ma rom ne fait pas 9pétaoctets pour embarquer le commentaire de l'algorithme de wxy. Bref, cela ne me semble pas généralisable comme approche encore spécifique..

C'est vrai que sur une doc qui a un peu vécu, il arrive un moment où on ne sait plus si la doc est fiable (surtout si le code semble faire autre chose que la doc).

J'ajouterais également, que malheureusement, c'est la même chose avec les commentaires dans le code. Dès que le code a un peu vécu, tu finis aussi par te demander si les commentaires sont encore fiables.

Cela mets en évidence à quel point la difficulté de gérer la documentation et que le code est le document de programmation pas d'architecture, de conception, d'algorithmes tout cela vous devriez le manifester ailleurs sur un blog par exemple

[pseudocode]

Aussi, j'ai écris des programmes où chaque caractère d'un commentaire compte comme un octet. Le programme n'est pas chargé en mémoire vive puisque c'est embarqué sur du matériel électronique et ma rom ne fait pas 9pétaoctets pour embarquer le commentaire de l'algorithme de wxy. Bref, cela ne me semble pas généralisable comme approche encore spécifique..

Tes commentaires apparaissent dans le code compilé ?

[hegros]

Tes commentaires apparaissent dans le code compilé ?

oui Mais bon combien de fois cela m'a sorti rééllement d'un vrai pétrin ?

Généralise aux satellites pour le matériel embarqué tu ne vas pas embarquer les commentaires de Newton avec un micro-code d'une micro-puce d'un micro-élément

[pseudocode]

oui Mais bon combien de fois cela m'a sorti rééllement d'un vrai pétrin ?

Généralise aux satellites pour le matériel embarqué tu ne vas pas embarquer les commentaires de Newton avec un micro-code d'une micro-puce d'un micro-élément

Non bien sur. Mais moi quand je compile du code embarqué, ca me génère un binaire sans commentaires et généralement optimisé pour réduire la taille.

Après on range quelque part les sources du code, le binaire et sa signature md5. Ca permet d'identifier les sources a partir d'une flash, pour peu que la flash soit lisible.

[hegros]

Non bien sur. Mais moi quand je compile du code embarqué, ca me génère un binaire sans commentaires et généralement optimisé pour réduire la taille.

Pour les téléphones ou les consoles j'ai également un doute. Enfin, le code embarqué en fait c'est du pascal et chaque ligne de commentaire compte comme une ligne de programme d'ailleurs c'est toujours le cas avec les delphis 6 chaque ligne de commentaire est compilé

Après on range quelque part les sources du code, le binaire et sa signature md5. Ca permet d'identifier les sources a partir d'une flash, pour peu que la flash soit lisible.

Mais c'est quoi l'histoire ? La terre explose la flash reste lisible des extra-terrestre l'insére dans leur super-extra mégatechnologie puis execute un programme dont le matériel ne se vends plus

En même temps techniquement cela me dépasse et la signature intégre aussi une fonction qui valide les commentaires ?

[Jedai]

Pour les téléphones ou les consoles j'ai également un doute. Enfin, le code embarqué en fait c'est du pascal et chaque ligne de commentaire compte comme une ligne de programme d'ailleurs c'est toujours le cas avec les delphis 6 chaque ligne de commentaire est compilé

C'est n'importe quoi ton histoire... Je n'ai jamais vu un seul compilateur qui tienne compte des commentaires dans la compilation. Les binaires ne contiennent pas les commentaires du code, c'est ridicule.

--
Jedaï

[el_slapper]

Tu as des états vraisemblablements exclusifs dans ton code (à priori, on aurait soit PAIEMENT_A, soit PAIEMENT_B, mais jamais les deux à la fois) mais ça ne se voit pas clairement, il n'y a aucun moyen d'en être sûr.

Le choix d'utiliser des booléens est donc mauvais à mon sens, une énumération aurait sûrement été préférable (après, je ne connais pas Cobol, peut-être n'est-ce pas possible).

en fait, c'est presque ça(si j'ai bien compris les énumérations), c'est des "niveaux 88". on a une variable "TYPE_PAIEMENT", et un booléen qui s'active automatiquement suivant la valeur :

Code :

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

1
2
3
4
5
6
01 TYPE-PAIEMENT PIC X(1).
   88 PAIEMENT-A VALUE 'A'.
   88 PAIEMENT-B VALUE 'B'.
   88 PAIEMENT-C VALUE 'C'
   88 PAIEMENT-AUTRE VALUE 'D' THRU 'Z'

J'ai une moulinette qui me calcule le type de paiement - sur un seul caractère. Plutôt que dire IF TYPE-PAIEMENT = 'A', je préfère dire IF PAIEMENT-A(avec un vrai libéllé plus long et plus explicite, mais que je ne peux pas donner ici).

Mais je ne sais pas si j'ai bien compris ton message. Et je suis toujours preneur d'améliorations(surtout de gens venant d'autres langages, il peuvent avoir des idées que les habitués ne verront même pas). Le code totalement propre, ça n'existe pas, il y a toujours de la place pour s'améliorer.

[white_tentacle]

Là, je crois que c'est ma méconnaissance totale de COBOL qui joue.

En C++ (mais ça vaut aussi pour Ada, C#, Java, etc...), je ferais quelque chose du genre :

Code :

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

1
2
3
4
5
6
7
enum TypePaiement
{
  PaiementA,
  PaiementB,
  PaiementC,
...
};

puis, toujours :

Code :

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

1
2
3
4
5
switch(typePaiement)
  case PaiementA:
  ....
  case PaiementB:
  ....

C'est très lisible, et en plus, le compilateur est capable de me donner un warning ou une erreur si j'ai oublié un cas dans mon switch (très utile lorsqu'on rajoute un type de paiement).

Cela dit, je viens de regarder rapidement ce que sont des "Niveaux 88", et effectivement, ma remarque initiale ne s'applique pas ici (par contre, le mécanisme même des niveaux 88 me semble plutôt contre intuitif).