Discussion :

[hegros]

Parce que tu penses que la doc externe est plus à jour que la doc interne ????????????




Dans 99.99999% des cas que j'ai vu, c'est le contraire...

Non mais toi et Jedai êtes quand même à l'ouest et dépassé sur ce sujet.


Tu sais c'est quoi un outil de rétro-ingénierie ? Si oui tu devrais savoir alors qu'il y a des merges etc ce qui fait que la doc qu'il génére est la plus à jour possible qu'il soit par rapport au code.

[mayayu]

Les hostilités sont ouvertes http://www.developpez.net/forums/d74...r-code-source/.

[GrandFather]

Par contre parfois, ce qui peut poser problème c'est l'envie (ou parfois l'obligation) de trop bien faire. La multiplication des niveaux d'abstraction, l'utilisation de classe proxy dans tous les coins, le découpage excessif des responsabilités... l'utilisation d'un tas de pattern (parfois à juste titre) Font que pour comprendre un bout de code de 10 lignes on finit par parcourir de multiples fichiers de code, à ne plus savoir ce qu'on manipule...

Ce que tu décris relève plus de l'architecture mal conçue que du code mal écrit... L'utilisation de pattern (à bon escient) rend, à cause du niveau d'indirection, le code un peu plus difficile à lire mais l'application est plus facile à maintenir. Ce qui semble être un paradoxe n'en est pas un : avec une architecture objet bien pensée, la lecture intégrale du code n'est pas nécessaire pour faire évoluer ou maintenir l'ensemble.

[pseudocode]

Tu sais c'est quoi un outil de rétro-ingénierie ? Si oui tu devrais savoir alors qu'il y a des merges etc ce qui fait que la doc qu'il génére est la plus à jour possible qu'il soit par rapport au code.

Bah, je t'en prie. Fait de la rétro-ingénierie sur le code suivant :

Code c :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
#include  <stdio.h>
#define   l "=================================================="
#define   m "                                                  "
int       _(
float     x,
float     y){
return    x>=0&&x<50&&y>=0&&y<20;}
int main  (){
char      a[2][20][51],c[9][4][51][51],d[100];
int       e,f,g,h=0,i,j=0,k,b=0,n[9],o[9],p[9],x[9],y[9],q[9],r,s,t;
float     u[9],v[9],w[9],z[9];
printf    ("i%s\033Yppppppppppppppppppp1G0",l);
do sprintf(a[0][j],"%s",m,
sprintf   (a[1][j],"%s",l));
while     (++j<20);
scanf     ("%d %d\n",&r,&s);
gets      (d);
do        {
sscanf    (d,"%d %d %f %f %f %f %d %d %d",&o[b],&p[b],&u[b],&v[b],&w[b],&z[b],&x[b],&y[b],&q[b],j=n[b]=i=0);
do do     c[b][i][j][x[b]]=!
gets      (c[b][i][j]);
while     (++j<y[b]);
while     (++i<q[b]+(j=0)||!++b);}
while     (
gets      (d)||(i=t=e=f=0));
do        {
do strncpy(a[h][i],m,50);
while     (++i<20||(i=0));
do if     (t>=o[i]&&t<=p[i]&&!(k=j=0))
do do if  (_(u[i]+k,v[i]+j))a[h][(
int       )v[i]+j][(
int       )u[i]+k]=c[i][n[i]][j][k];
while     (++k<x[i]);
while     (++j<y[i]+(k=0)||((++n[i]-q[i]||(n[i]=0)),u[i]+=w[i],v[i]+=z[i],0));
while     (++i<b||(k=j=g=0));
do do if  (a[1-h][j][k]!=a[h][j][k]){f-j&&
printf    ("%dG0",j+1,e=0,g+=4);k&&e>k&&
printf    ("0%d ",k,g+=4);k&&e<k&&k-e>1&&
printf    ("%d ",k-e,g+=3);k&&e<k&&k-e==1&&
printf    (" ",g++);
printf    ("r%c",a[h][j][k],g+=2,e=k,f=j);}
while     (++k<50);
while     (++j<20+(k=0));
do printf ("1G0",g+=3,e=f=0);
while     (g<s);h=1-h;}
while     (++t<=r+(i=0));
return    !
puts      ("");}

[GrandFather]

Bah, je t'en prie. Fait de la rétro-ingénierie sur le code suivant :

Joli... C'est du BrainFuck++ ?

[souviron34]

Non mais toi et Jedai êtes quand même à l'ouest et dépassé sur ce sujet.


Tu sais c'est quoi un outil de rétro-ingénierie ? Si oui tu devrais savoir alors qu'il y a des merges etc ce qui fait que la doc qu'il génére est la plus à jour possible qu'il soit par rapport au code.

On en reparlera quand tu auras travaillé sur du vrai code...

Pour te dire un exemple : là je suis sur 100 000 lignes de Fortran 77, codé comme un cochon... sans pouvoir le compiler.. Eh bien je peux te dire que même avec des commentaires dans le code, même avec de la doc, d'une part aucun logiciel de rétro-ingéiérie ne remontera ça, et d'autre part même à 3 très expérimentés dessus on a du mal...

Mais bon, tu es persuadé de ton fait.. Tant mieux pour toi..

Et tant pis pour ceux qui voudront reprendre ton code dans 15 ans..

PS : et n'importe quel code comme l'a montré pseudocode est intraçable sans 'arracher les cheveux, et ne parlons pas de programmation événementielle, ou la rétro-ingénierie ne peut rien faire..

[pseudocode]

Joli... C'est du BrainFuck++ ?

Non. C'est du langage C tout ce qu'il y a de plus normal.

The International Obfuscated C Code Contest

[GrandFather]

Il est certain que FORTRAN s'accommode plus de l'ingénierie rétro que de la rétro-ingénierie...

[sleepy2002]

Salut,

Selon moi, un code propre l'est au sens où :

• il respecte une convention d'écriture (exemple convention Sun pour java),
• dans le cadre de la poo, il respecte le principe d'ouverture / fermeture et le principe de Substitution de Liskov ,
• il est couvert par un bon test unitaire. Celui-ci doit clairement décrire le comportement attendu (contrat) en fonction des cas d'utilisations (basique et/ou extrême),
• un ensemble d'outils d'analyse de code veille au grain (par exemple en java FindBugs, Cobertura),
• les commentaires "intra méthode" sont absents (le code s'autodocumente via un nommage explicite des méthodes, des variables, attributs et classes),
• dans le cadre d'une publication d'une API, les commentaires en entête de méthode pertinents qui vont à l'essentiel avec un exemple d'utilisation si possible (Les commentaires sur les setters / getters sont inutiles par exemple)

Ne pas oublier :

Do the simplest thing that could possibly work.
Ron Jeffries (un des auteurs de la méthodologie XP)

[souviron34]

Il est certain que FORTRAN s'accommode plus de l'ingénierie rétro que de la rétro-ingénierie...

Fallait la faire

et elle est bonne..

[souviron34]

• les commentaires "intra méthode" sont absents (le code s'autodocumente via un nommage explicite des méthodes, des variables, attributs et classes),

je ne peux pas être d'accord avec ça...

[mathbzh]

Ce que tu décris relève plus de l'architecture mal conçue que du code mal écrit... L'utilisation de pattern (à bon escient) rend, à cause du niveau d'indirection, le code un peu plus difficile à lire mais l'application est plus facile à maintenir. Ce qui semble être un paradoxe n'en est pas un : avec une architecture objet bien pensée, la lecture intégrale du code n'est pas nécessaire pour faire évoluer ou maintenir l'ensemble.

On est d'accord... mais au final le code devient tout de même illisible.

Disons que mon message concerne un peu la tendance de pas mal de développeur (moi le premier). A concevoir des machins compliqués au non de la sacro-sainte "maintenabilité".

[GrandFather]

Disons que mon message concerne un peu la tendance de pas mal de développeur (moi le premier). A concevoir des machins compliqués au non de la sacro-sainte "maintenabilité".

Comme tu l'as dis, c'est un équilibre à trouver, pas toujours évident. Il faut éviter une architecture compliquée, mais ne pas hésiter quand il le faut à utiliser une architecture complexe.

les commentaires "intra méthode" sont absents (le code s'autodocumente via un nommage explicite des méthodes, des variables, attributs et classes),

Je suis d'accord, à un détail près : il est bon d'utiliser un commentaire pour expliquer un fragment de code peu évident, conçu de cette manière pour des raisons d'optimisation ou, par exemple, pour contourner un bug d'une librairie appelée ; c'est se rendre service et rendre service à ceux qui liront ton code.

[Matthieu Brucher]

J'aimerais bien qu'on me cite un extrait d'une méthode logiciellle (qu'elle qu'elle soit), agile ou non, recommandant de ne pas mettre de commentaires dans son code.....

XP ?
Les méthodes agiles recommandent de ne pas documenter le code (idem dans les ouvrages sur le code propre).

[Matthieu Brucher]

En général, le code, même compliqué, même non commenté, même avec des noms de variables peu inspiré... reste relativement facile à lire (OK, il y a des bouts de codes de psychopathes particulièrement obscurs mais finalement j'en ai rencontré assez peu dans ma carrière).

Désolé, mais tu n'as pas dû lire beaucoup de code alors. Dans ce que je lis régulièrement, c'est extrêmement difficile à comprendre. Quand c'est possible.

[Matthieu Brucher]

Pour te dire un exemple : là je suis sur 100 000 lignes de Fortran 77, codé comme un cochon... sans pouvoir le compiler.. Eh bien je peux te dire que même avec des commentaires dans le code, même avec de la doc, d'une part aucun logiciel de rétro-ingéiérie ne remontera ça, et d'autre part même à 3 très expérimentés dessus on a du mal...

Je veux bien te croire... J'en vois aussi régulièrement. Heureusement qu'il y a le 90, mais c'est pas encore gagné ! (pourtant, il est bien plus rapide, va comprendre).

je ne peux pas être d'accord avec ça...

Moi si. La méthode/fonction aurait dû être refactorée si elle est incompréhensible.

[rad_hass]

J'aimerais beaucoup vous voir, toi ou rad_hass, dans 10 ou 15 ans, en train d'essayer de reprendre un de vos codes... (ou celui d'un autre)....

Je ne comprends pas trop le pourquoi de cette phrase, on dirait presque de la provocation, mais moi je ne suis pas là pour ça ;-) ...

A chacun sa vérité ...

Je voudrais laisser deux billets que je trouve amusant qui vienne du monde agile :

Avec beaucoup d'humour il y a celui-ci :

http://www.christian-faure.net/2008/...ature-de-code/

Ou celui là :

http://etienne.charignon.free.fr/spi....php?article61

[hegros]

Bah, je t'en prie. Fait de la rétro-ingénierie sur le code suivant :

Code c :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
#include  <stdio.h>
#define   l "=================================================="
#define   m "                                                  "
int       _(
float     x,
float     y){
return    x>=0&&x<50&&y>=0&&y<20;}
int main  (){
char      a[2][20][51],c[9][4][51][51],d[100];
int       e,f,g,h=0,i,j=0,k,b=0,n[9],o[9],p[9],x[9],y[9],q[9],r,s,t;
float     u[9],v[9],w[9],z[9];
printf    ("i%s\033Yppppppppppppppppppp1G0",l);
do sprintf(a[0][j],"%s",m,
sprintf   (a[1][j],"%s",l));
while     (++j<20);
scanf     ("%d %d\n",&r,&s);
gets      (d);
do        {
sscanf    (d,"%d %d %f %f %f %f %d %d %d",&o[b],&p[b],&u[b],&v[b],&w[b],&z[b],&x[b],&y[b],&q[b],j=n[b]=i=0);
do do     c[b][i][j][x[b]]=!
gets      (c[b][i][j]);
while     (++j<y[b]);
while     (++i<q[b]+(j=0)||!++b);}
while     (
gets      (d)||(i=t=e=f=0));
do        {
do strncpy(a[h][i],m,50);
while     (++i<20||(i=0));
do if     (t>=o[i]&&t<=p[i]&&!(k=j=0))
do do if  (_(u[i]+k,v[i]+j))a[h][(
int       )v[i]+j][(
int       )u[i]+k]=c[i][n[i]][j][k];
while     (++k<x[i]);
while     (++j<y[i]+(k=0)||((++n[i]-q[i]||(n[i]=0)),u[i]+=w[i],v[i]+=z[i],0));
while     (++i<b||(k=j=g=0));
do do if  (a[1-h][j][k]!=a[h][j][k]){f-j&&
printf    ("%dG0",j+1,e=0,g+=4);k&&e>k&&
printf    ("0%d ",k,g+=4);k&&e<k&&k-e>1&&
printf    ("%d ",k-e,g+=3);k&&e<k&&k-e==1&&
printf    (" ",g++);
printf    ("r%c",a[h][j][k],g+=2,e=k,f=j);}
while     (++k<50);
while     (++j<20+(k=0));
do printf ("1G0",g+=3,e=f=0);
while     (g<s);h=1-h;}
while     (++t<=r+(i=0));
return    !
puts      ("");}

Ce code ne passe pas la simple revue de code avec 2 programmeurs tout niveaux(en 10secondes montre en main). Un outil s'utilise à bon escient il est évidemment à la simple lecture humaine qu'on en tirera rien alors pourquoi faire tourner la machine ?



Souviron tu dis que dans ton projet Fortran les commentaires ne te servent à rien et tu t'entêtes à affirmer qu'ils sont indispensable alors que l'expérience (sur un très gros projet en l'occurence le tien) montre le contraire...

[mathbzh]

Désolé, mais tu n'as pas dû lire beaucoup de code alors. Dans ce que je lis régulièrement, c'est extrêmement difficile à comprendre. Quand c'est possible.

Méa-culpa, je n'ai pas été assez précis. Je voulais parler du code sur lequel je travaille, pas du "Code" en général. Le psychopathe dont je parlais est un gars très... comment dirais je... cérébral. Qui n'est plus là mais est intervenue sur quelques parties sensibles (complexe ou a optimiser) du projet à l'origine.

Dans d'autre circonstance il m'arrive évidemment de tomber sur du code que je ne comprend pas.

[gl]

C'est spécifique au langage en C c'est 0 en W-Langage c'est 1, bref cela n'a rien à faire comme un commentaire de code (cela ressemblerait à un commentaire du langage...)

Ca c'est les bornes d'un tableau natif dans le langage. Rien n'empêche dans ladite fonction de changer de convention (et donc de prendre 1 pour le premier caractère en C), même si ce n'est clairement pas une bonne idée.

Par contre pour rester dans l'esprit de la remarque, il peut être possible de préciser par exemple le cas des nombres négatifs (simplement refusé, décalage par rapport à la fin de la chaîne, etc.)

Avec le commentaire c'est surement pas plus clair !

Un commentaire peut être largement plus grand que le nom d'une fonction et à l'avantage d'être structuré. Il est donc possible de rendre le commentaire plus clair que le simple nom de fonction.

Quant à l'intérêt de commenter les fonctions de manière assez complète, j'en vois au moins deux:

• Générer la documentation du code automatiquement à partir des commentaires, ce qui peut facilement s'intégrer dans le processus de génération et permet de détecter facilement des incohérences entre le code et les commentaires (et donc la documentation).
• Les éditeurs un minimum évolués permettent de sauter directement à la déclaration d'une fonction ou d'afficher dans une popup le commentaire d'une fonction, voire les deux. Ce qui est largement plus rapide et pratique que de se référer à une documentation externe.

PS: pour préciser clairement le contexte de mon message, je parle ici des commentaires d'en-tête de fichier et d'en-tête de fonction.
Pour les commentaires internes à une fonction/méthode/procédure, j'ai une approche plus minimaliste, commentant uniquement les passages les plus ambigus (tordus?) ou certains choix d'implémentation surprenant qui ne font pas (et n'ont pas à faire) l'objet d'un document externe.