Qu'est-ce qu'un code "propre" selon vous ?

Version imprimable

Voir 40 message(s) de cette discussion en une page

19/05/2009, 20h42
gl

Citation:

Envoyé par hegros

En pascal sur du matériel Schneider TéléMécanique, chaque ligne de commentaire compte comme un octet et biensûr que oui que je vois à l'execution les commentaires en clair dans la mémoire

En Pascal, je n'en sais rien, mais dans la plupart des langage utilisés en embarqué (ASM, C, C++, Java et probablement d'autre), les commentaires ne sont plus présents dans le binaire généré (que ce soit systématique ou en fonction d'une option de génération du binaire).

Quant au langage qui embarquerait les commentaires dans le binaire généré, ça ne me semble pas être un argument pertinent pour supprimer tout les commentaires du code.
Il est, à mon avis, plus pertinent d'intégrer dans la chaîne de compilation une étape générant des fichiers sources temporaires sans commentaire que de prohiber tout commentaires.
19/05/2009, 21h39
hegros

Citation:

Envoyé par gl

Un commentaire peut être largement plus grand que le nom d'une fonction et à l'avantage d'être structuré...

Biensûr qu'un commentaire est largement plus grand que le nom d'une fonction puisque tu peux l'exprimer sur des lignes et des lignes de programme. Au final on a un un % de commentaire plus important que % de code ce qui pose quand même un problème :koi:

Citation:

Envoyé par gl

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).

Oui tu précises bien la documentation car en fait ce que tu nous dis entraîne une duplication de la documentation ce qui pose quand même problème notamment d'incohérence.

Pour l'embarqué je ne sais pas à quoi tu penses il y en a tellement...Tu cites des langages sans nommer de plateformes ? En tout cas le fournisseur est le leader mondial des systèmes automatisés et informatisés pour l'industrie et utilise aussi les technologies à base de java .net xml web etc...
19/05/2009, 22h44
FR119492

Citation:

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

C'est certainement sur www.netlib.org qu'on trouve les bibliothèques les plus performantes pour le calcul numérique. Or l'immense majorité de ces bibliothèques sont écrites en Fortran. Curieux, n'est-ce pas...
D'autre part, Intel, sans conteste un leader pour les processeurs à hautes performances met gratuitement à disposition un compilateur Fortran constamment remis à jour. Pourquoi donc?
Jean-Marc Blanc
19/05/2009, 22h47
FR119492

Salut Souviron34!

Citation:

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...

Tu ne cherches pas un quatrième, par hasard?
Jean-Marc
20/05/2009, 00h16
gl

Citation:

Envoyé par hegros

Biensûr qu'un commentaire est largement plus grand que le nom d'une fonction puisque tu peux l'exprimer sur des lignes et des lignes de programme. Au final on a un un % de commentaire plus important que % de code ce qui pose quand même un problème :koi:

D'une part, il n'y a pas nécessairement plus de commentaires que de code. Les commentaires ne sont pas une fin en soi et je ne préconise pas de mettre des kilomètres de commentaires pour mettre des commentaires, seulement ce qui est utile.

D'autre part, quel critère objectif permet d'affirmer qu'un % de commentaire plus important que le % de code est un problème ?

Citation:

Envoyé par hegros

Oui tu précises bien la documentation car en fait ce que tu nous dis entraîne une duplication de la documentation ce qui pose quand même problème notamment d'incohérence.

La doc étant généré à partir du commentaire, il ne peut y avoir d'incohérence entre les deux. Et le processus de génération permet de repérer d'éventuelle différence entre le code et la documentation, ce que ne permet pas une documentation maintenue manuellement indépendant du code.
Contrairement à ce que tu prétends, la génération de doc à partir du commentaire permet ainsi de réduire le risque d'incohérence.

Citation:

Envoyé par hegros

Pour l'embarqué je ne sais pas à quoi tu penses il y en a tellement...Tu cites des langages sans nommer de plateformes ?

Terminaux de payement, téléphone portable, équipement réseau et téléphonique, Distributeur de carburant, carte à puce, péage, DAB/GAB, caisse enregistreuse (quoique dans les deux derniers exemple on est limite dans le domaine du PC classique).

Il est tout à fait possible de trouver d'autres langages sur du matériel embarqué (si mes sources sont bonnes, Ada et Erlang sont très utilisés dans certains domaines) mais il faut reconnaitre que C et C++ restent très présent dans ce domaine, ne serait-ce que grâce à la disponibilité d'un compilateur sur quasiment toutes les architectures, contrairement de nombreux autres langages.

Quant à l'utilisation du Pascal, je te crois volontiers lorsque tu dis que c'est utilisé, mais dans mon expérience personnelle, je n'en ai jamais rencontré dans de l'embarqué (ce qui ne signifie pas que ce soit insignifiant bien sur).
20/05/2009, 00h46
souviron34

Citation:

Envoyé par Matthieu Brucher

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

Sauf que justement, quand c'est toi qui fait le refactoring, ton argument tombe :P

Citation:

Envoyé par rad_hass

A chacun sa vérité ...

c'est vrai, mais à chacun son expérience aussi...

Je dis juste attendons que tu aies 15 ans de plus, et je met ma main au feu que ton avis aura changé.. ;)

Citation:

Envoyé par hegros

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...

Non, je dis que ça aide, mais que même avec ça, ça n'empêche pas, si il est mal fait d'une part, ou si on ne peut forcément s'y fier, que cela reste un problème..

Mais le problème est cependant beaucoup moins fort quand on sait que txcfrl() correspond aux tableaux des taux par niveaux que quand il faut essayer d'en chercher la signifcation ailleurs dans le code...

Je dis que si il n'y avait pas de commenaires dans le code, ma solution serait simple : tout reprendre à zéro, c'est à dire 25 ans de développement.. et environ 70 millions d'euros..

Alors que là, même en étant le b.rdel, avec des commentaires et quelques docs dont il faut vérifier à chaque fois la validité, ça se réduit quand même à un peu moins d'un an et un peu moins du million...

Citation:

Envoyé par FR119492

Salut Souviron34!

Tu ne cherches pas un quatrième, par hasard?

8-) j'aimerais bien.. Tu as lu de l'autre côté le genre de code que c'est... Malheureusement, je ne décide pas.. Si une ouverture nouvelle se fait, ou que j'ai envie de laisser ma place, je te contacte :)
20/05/2009, 00h50
souviron34

Citation:

Envoyé par Matthieu Brucher

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

il faut que je retouve, on avait cité quelque part l'oriignal de l'auteur original, celui qui a "mis au clair" le premier une "méthode" agile....

Mais je suis absolument certain, et si des gens disent ça, et l'expose dans des bouquins, eh bien c'est qu'ils n'envisagent que des applications jetables... et c'est absolument une aberration.. Que ce soit en "méthode agile" ou non...

Mais cela serait bien dans l'air du temps...
20/05/2009, 01h01
souviron34

je voulais d'ailleurs rajouter ici un lien sur un autre débat de ce même forum, qui est lié :

Une conception ou un code sale sont-ils un danger pour l'entreprise ?
20/05/2009, 07h40
Matthieu Brucher

Citation:

Envoyé par souviron34

Sauf que justement, quand c'est toi qui fait le refactoring, ton argument tombe :P

Ben non, le code propre, ce n'est pas du code propre juste pour moi.

Citation:

Envoyé par souviron34

il faut que je retouve, on avait cité quelque part l'oriignal de l'auteur original, celui qui a "mis au clair" le premier une "méthode" agile....

Mais je suis absolument certain, et si des gens disent ça, et l'expose dans des bouquins, eh bien c'est qu'ils n'envisagent que des applications jetables... et c'est absolument une aberration.. Que ce soit en "méthode agile" ou non...

Mais cela serait bien dans l'air du temps...

Disons que pour moi, il y a la théorie et la pratique. Documentation des fonctions pour la documentation du code, et ensuite des pdf avec le fonctionnement global, I/O, ...
20/05/2009, 09h36
el_slapper
Citation:

Envoyé par Matthieu Brucher

Ben non, le code propre, ce n'est pas du code propre juste pour moi.

Disons que pour moi, il y a la théorie et la pratique. Documentation des fonctions pour la documentation du code, et ensuite des pdf avec le fonctionnement global, I/O, ...

La doc, elle disparait. Le code reste. Ma mission actuelle consiste à saucissoner un vieux programme COBOL de 1972 pour progressivement le vider de sa substance en sortant une a une chacune de ses fonctions(il fait de la compta, de la gestion d'éditions, de la mise à jour de bases et tout un tas de trucs techniques). Non seulement la doc a disparu, mais les gens qui l'avaient conçu sont à la retraite, ou morts. De toutes façon, personne ne sait qui ils étaient.

La seule chose qui reste, c'est le code. Peut-être mes morceaux à moi subiront le même sort dans 30 ans. Et là, mes successeurs seront contents d'avoir quelques commentaires.

EDIT : evidemment, sur l'exemple que j'ai donné, si le commentaire explique que le code décide du type de courrier en fonction du type de paiement, il ne sert à rien. Par contre, si il donne le contexte général et rappelle pourquoi le TIP a des contraintes particulières, alors il est bien plus utile. Le danger, c'est :
Code:

1 2 3 4 *si montant supérieur à 1M€, pas de TIP IF MONTANT > 100000000 SET TIP-INTERDIT TO TRUE END-IF
Par contre, expliquer pourquoi :
Code:

1 2 3 4 5 *limite technique, le masque des TIP ne gère pas les montants *supérieurs à 1M€ IF MONTANT > 100000000 SET TIP-INTERDIT TO TRUE END-IF
.....peut permettre de comprendre au prochain refactoreur le pourquoi du bouzin, et eventuellement d'en discuter avec les gens des métiers, savoir si cette limite est toujours d'actualité, etc.....
20/05/2009, 09h39
white_tentacle

Citation:

Disons que pour moi, il y a la théorie et la pratique. Documentation des fonctions pour la documentation du code, et ensuite des pdf avec le fonctionnement global, I/O, ...

Je commence à m'habituer à intégrer tout cela aussi directement dans le code. Avec doxygen + dot + latex, on arrive à faire vraiment de jolies choses, bien complètes. Rien à envier à un document word, et j'ai la doc d'archi et les specs de mes fonctions dans le même "document" (pages html) final

En plus, je n'ai pas à modifier à 3 endroits différents chaque fois que je fais une modification (ce qui est la principale raison de la non mise à jour des docs).

Citation:

Ben non, le code propre, ce n'est pas du code propre juste pour moi.

J'aime vraiment beaucoup le paradoxe de cette phrase :mouarf:
20/05/2009, 09h54
souviron34

Citation:

Envoyé par Matthieu Brucher

Ben non, le code propre, ce n'est pas du code propre juste pour moi.

tu ne comprends pas ce que je dis.

Comme le dit el_slapper, la documentation ET les auteurs ont disparu...

Tu te retrouves avec le code, qui n'est qu'une (petite) partie d'un gros tout... Sauf que visiblement tu y passes..

Alors si la "méthode" fait a+b, pas de problèmes.

Dès qu'elle fait un algo un tant soit peu compliqué, avec des hypothèses de travail qui par exemple ne sont plus du tout en place (admettons par exemple que ce soit sur un statut d'entreprise, et que cela réfère au statut d'auto-entrepeneur, et qu'on est en 2022, où le statut a disparu depuis 10 ans..), si il n'y a aucun commentaire et que le code fait juste référence à "statut" sans préciser quoi que coit dans un commentaire, ben t'es dans la m.rde..

Mais même sans faire appel à quelque chose qui a disparu, dès que l'algo est un tant soit peu complexe (regarde ce qui se fait en traitement d'images ou en mathématiques : juste une inversion de matrice par la méthode du pivot de Gauss), déchiffrer le code ligne à ligne pour comprendre ce que fait chaque ligne, plutôt que d'avoir un commenaire identifiant le but de chaque bloc, est une hooreur cérébrale...

Et même si il y a un bon commentaire en tête du fichier, dès que la "méthode" dépasse 20 lignes et qu'elle commence à être complexe, des commentaires au milieu du code sont bienvenus....
20/05/2009, 10h03
Brzhk

Bon, je viens de découvrir ce thread qui m'a particulièrement passionné étant donné mon travail ( faire évoluer un code fortran 77. Je salue les précédents posteurs qui ont le même fardeau ^^).

A force de lire ce code, je commence à développer une espece d'expertise du code moche. Et j'ai une définition du code propre qui me suffit:

Un code propre c'est un code dont une seule ligne suffit a comprendre ce qu'elle fait.

Autrement dit:
Pas besoin de se taper le reste du code pour comprendre. Donc, des noms de variables clairs & des noms de fonctions tout aussi clairs. C'est la base d'un code débugguable: si une fonction est nommée 'addition' et qu'elle renvoie une division, alors vous trouvez irrémédiablement le bug rapidement. (c'est simplifié, mais le principe reste le même)

Si c'est une fonction de 2500 lignes en fortran 77 qui prend 135 paramètres aux noms obscurs et qui s'appelle 'traln2', vous ne comprenez rien.Et vous vous tapez la lecture des autres procédures tout aussi poétiquement nommées pour comprendre leur rôle.
20/05/2009, 10h08
Brzhk

(aussi )

Je lisais plus haut qu'une procédure prenait 2500 lignes de codes pour faire un affichage, et qu'on pouvait pas faire mieux.
Je suis extremement dubitatif. L'argument avancé était qu'une division de cette procédure en morceaux aurait généré des fonctions avec un nombre enorme de paramètres.

C'est faire fi de la construction de structures : regrouper des parametres afin d'augmenter la lisibilité du code.
ex:

typedef struct point { int x; int y;}point;

et hop.

@Matthieu Brucher :

un exemple...

Tu prends le code (fourni gracieusement et publiquement par pseudocode dans la rubrique Algorithmes -> Contribuez :D) :

Dans lequel j'ai enlevé tout le commentaire...

Code:

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
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
 
/**
 * Hough Transform
 * 
 * @author Xavier Philippeau
 *
 */
public class Hough {
 
	private int Width,Height;
 	private double maxRho;
 	private int maxIndexTheta,maxIndexRho;
	int[][] acc;
 
	public Hough(int width,int height) {
		this.Width=width;
		this.Height=height;
 
		this.maxRho = Math.sqrt( width*width + height*height );
		this.maxIndexTheta=360;
		this.maxIndexRho=(int)(1+this.maxRho);
		this.acc = new int[maxIndexTheta][maxIndexRho];
	}
 
	public void vote(int x,int y) {
		x-=Width/2;	y-=Height/2;
 
		for(int indexTheta=0; indexTheta<maxIndexTheta; indexTheta+=1) {
			double theta = ((double)indexTheta/maxIndexTheta)*Math.PI;
			double rho = x*Math.cos(theta) + y*Math.sin(theta);
			int indexRho   = (int) (0.5 + (rho/this.maxRho + 0.5)*this.maxIndexRho );
			acc[indexTheta][indexRho]++;
		}
	}
 
	public double[] winner() {
		double max=0, winrho=0, wintheta=0;
		for(int r=0;r<maxIndexRho;r++) {
			for(int t=0;t<maxIndexTheta;t++) {
				if (acc[t][r]<max) continue;
				max=acc[t][r];
				winrho=r;
				wintheta=t;
			}
		}
 
		double rho   = ((double)winrho/this.maxIndexRho - 0.5)*this.maxRho;
		double theta = ((double)wintheta/this.maxIndexTheta)*Math.PI;
 
		return new double[] {rho,theta};
	}
 
	public double[] rhotheta_to_ab(double rho, double theta) {
		double a=0,b=0;
		if(Math.sin(theta)!=0) {
			a = -Math.cos(theta)/Math.sin(theta);
			b = rho/Math.sin(theta)+Height/2-a*Width/2;
		} else {
			a=Double.MAX_VALUE;
			b=0;
		}
		return new double[] {a,b};
	}
}

Très nettement plus difficile à comprendre que le code avec les commentaires exposé dans l'article image detecteur de lignes de Hough

De même, issue de moi-même, une routine de maths en Fortran, à laquelle on a enlevé les commentaires :

Code:

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
C***********************************************************C
C       SOLVE LINEAR SYSTEM VIA GAUSSIAN ELIMINATION        C
C          ORDER UP TO 10                                   C
C             ( 10.01.1979 K. BANSE )                       C
C                              (SACLAY - HPCCD - 1982/84)   C
C***********************************************************C
        SUBROUTINE LNSYS(ARRAY,X,NORDER,IERR)
        DIMENSION ARRAY(10,11), X(10)
        DOUBLE PRECISION ARRAY, SAVE,RMAX,X
        IERR=0
        DO 100 K=1,NORDER-1
        SAVE=0.D0
        DO 30 J=K,NORDER
        RMAX=DABS(ARRAY(J,K))
        IF(SAVE.GE.RMAX)GO TO 30
        SAVE=RMAX
        MXROW=J
30      CONTINUE
        DO 40 J=K,NORDER+1
        SAVE=ARRAY(K,J)
        ARRAY(K,J)=ARRAY(MXROW,J)
        ARRAY(MXROW,J)=SAVE
40      CONTINUE
        IF(DABS(ARRAY(K,K)).LT.10.D-12) GO TO 300
        DO 60 I=K+1,NORDER
        SAVE=ARRAY(I,K)/ARRAY(K,K)
        ARRAY(I,K)=0.D0
        DO 61 J=K+1,NORDER+1
        ARRAY(I,J)=ARRAY(I,J)-SAVE*ARRAY(K,J)
61      CONTINUE
60      CONTINUE
100     CONTINUE
        X(NORDER)=ARRAY(NORDER,NORDER+1)/ARRAY(NORDER,NORDER)
        DO 200 NN=2,NORDER
        I=NORDER+1-NN
        SAVE=ARRAY(I,NORDER+1)
        DO 150 J=I+1,NORDER
        SAVE=SAVE-ARRAY(I,J)*X(J)
150     CONTINUE
        X(I)=SAVE/ARRAY(I,I)
200     CONTINUE
        GO TO 333
300     DO 310 N=1,NORDER
        X(N)=0.0
310     CONTINUE
        IERR=-1
333     RETURN 
        END

Par rapport à l'original figurant ici (Forum Algorithmes -> Contribuez) ellipse fitting algorithm

20/05/2009, 10h16
souviron34

Citation:

Envoyé par Brzhk

(aussi )

Je lisais plus haut qu'une procédure prenait 2500 lignes de codes pour faire un affichage, et qu'on pouvait pas faire mieux.
Je suis extremement dubitatif. L'argument avancé était qu'une division de cette procédure en morceaux aurait généré des fonctions avec un nombre enorme de paramètres.

C'est faire fi de la construction de structures : regrouper des parametres afin d'augmenter la lisibilité du code.
ex:

typedef struct point { int x; int y;}point;

et hop.

C'est faire fi de ce qui se passe dans une application complexe temps réel :P

Si tu as une boucle d'affichage temporel, et que tous les paramètres d'affichage sont dynamiques (y compris les données), tu as comme un petit problème...

Je n'ai pas dit que c'était ce qu'il fallait faire, j'ai dis que l'altenative, dans ce cas-là, était bien trop complexe, et aurait rendu le code (et la maintenance) bien plus difficle...

Et, sur un code de 750 000 lignes, avoir 2 routines de 2500 lignes, bof, c'est pas grand'chose (à peine 0.6 % du code)...

Qu'est-ce que tu crois : j'en avais pleins , de structures... Mais pour ce cas-là, il y avait des interactions dans tous les sens... J'ai mis 9 ans à le faire, ce soft, j'y ai réfléchi :D
20/05/2009, 10h36
Matthieu Brucher

Citation:

Envoyé par souviron34

tu ne comprends pas ce que je dis.

Comme le dit el_slapper, la documentation ET les auteurs ont disparu...

Tu te retrouves avec le code, qui n'est qu'une (petite) partie d'un gros tout... Sauf que visiblement tu y passes..

Alors si la "méthode" fait a+b, pas de problèmes.

Dès qu'elle fait un algo un tant soit peu compliqué, avec des hypothèses de travail qui par exemple ne sont plus du tout en place (admettons par exemple que ce soit sur un statut d'entreprise, et que cela réfère au statut d'auto-entrepeneur, et qu'on est en 2022, où le statut a disparu depuis 10 ans..), si il n'y a aucun commentaire et que le code fait juste référence à "statut" sans préciser quoi que coit dans un commentaire, ben t'es dans la m.rde..

Mais même sans faire appel à quelque chose qui a disparu, dès que l'algo est un tant soit peu complexe (regarde ce qui se fait en traitement d'images ou en mathématiques : juste une inversion de matrice par la méthode du pivot de Gauss), déchiffrer le code ligne à ligne pour comprendre ce que fait chaque ligne, plutôt que d'avoir un commenaire identifiant le but de chaque bloc, est une hooreur cérébrale...

Et même si il y a un bon commentaire en tête du fichier, dès que la "méthode" dépasse 20 lignes et qu'elle commence à être complexe, des commentaires au milieu du code sont bienvenus....

C'est donc que le code n'était pas propre, je pense qu'on est d'accord là-dessus ;)
Quand au "commentaire identifiant le début de chaque bloc", si le bloc était une fonction, le nom de la fonction permettrait de savoir ce qu'il en est, avec une référence globale à un article d'explication, on peut retrouver ses petits (je ne dis pas que dans le cas d'un outil complexe, ce soit forcément simple à comprendre tout de même, il faut réussir à comprendre l'article d'explication, déjà !).

Pour moi, ta routine Fortran est trop longue. OK, elle a été proposée dans ce forum, mais ce n'est pas pour ça que je dirai que c'est du code propre ;)
20/05/2009, 10h38
GrandFather

Citation:

Envoyé par FR119492

C'est certainement sur www.netlib.org qu'on trouve les bibliothèques les plus performantes pour le calcul numérique. Or l'immense majorité de ces bibliothèques sont écrites en Fortran. Curieux, n'est-ce pas...
D'autre part, Intel, sans conteste un leader pour les processeurs à hautes performances met gratuitement à disposition un compilateur Fortran constamment remis à jour. Pourquoi donc?
Jean-Marc Blanc

C'était de l'ironie, Jean-marc, n'y vois pas une charge contre Fortran. ;)
20/05/2009, 10h47
rad_hass

Citation:

Envoyé par souviron34

c'est vrai, mais à chacun son expérience aussi...

Je dis juste attendons que tu aies 15 ans de plus, et je met ma main au feu que ton avis aura changé.. ;)

lol et heureusement ;-)
Le jour où j'arrêterai d'apprendre, je changerai aussitôt de branche :D

Moi je ne dis pas être contre les commentaires, mais de mon avis ça doit être un dernier recours pour rendre un code propre ... D'ailleurs dans un livre de Martin Flower (avec la participation de Kent Beck inventeur d'XP) il fait une superbe métaphore sur les commentaires, les comparant à du déodorant qu'on utiliserai pour masquer les mauvaises odeurs (un code sale).
20/05/2009, 11h04
souviron34

Citation:

Envoyé par Matthieu Brucher

Quand au "commentaire identifiant le début de chaque bloc", si le bloc était une fonction, le nom de la fonction permettrait de savoir ce qu'il en est

Le problème est que pour la quasi-totalité des algos de maths, le "bloc" n'est pas une fonction, mais une étape dans l'algo...

Tu as des tableaux, tu fais des opérations, mais le tout se tient.. Et il y a un flux...

Ce n'est pas (forcément) découpable facilement en fonctions.... mais plutôt en "bloc d'objectifs"... d'où l'aspect documentaire des commentaires, pour savoir à quelle étape on en est...

Et même avec ceci , le code de pseudocode est limpide quand on prend en compte les commentaires, mais par exemple le fait de savoir que l'origine est à zéro ne serait pas évident si on n'avait pas les commentaires...

Citation:

Envoyé par Matthieu Brucher

Pour moi, ta routine Fortran est trop longue. OK, elle a été proposée dans ce forum, mais ce n'est pas pour ça que je dirai que c'est du code propre ;)

Primo je n'en suis pas l'auteur (voir la référence), donc je n'y touche pas (un algo est un algo, les droits d'auteur etc etc, et il faut pouvoir mettre une responsabilité en cas d'échec), et d'autre part c'est ce que je dis ci-dessus..

Avec les algos de maths, c'est nettement plus compliqué de découper en fonctions.. Tu fais un site Web, tu fais une appli de gestion, peut-être que c'est assez facile... Mais dans énormément de cas de programmation, ce n'est pas le cas....

Citation:

Envoyé par rad_hass

Le jour où j'arrêterai d'apprendre, je changerai aussitôt de branche :D

C'est pour ça qu'il ne faut pas être définitif dans sa manière de parler "c'est comme ça" ou "ça devrait être comme ça"... :D

Citation:

Envoyé par rad_hass

D'ailleurs dans un livre de Martin Flower (avec la participation de Kent Beck inventeur d'XP) il fait une superbe métaphore sur les commentaires, les comparant à du déodorant qu'on utiliserai pour masquer les mauvaises odeurs (un code sale).

D'une part tu apprendras que les livres ne sont que peu de choses face à la réalité, que les "méthodologies" c'est pareil..

D'autre part même en étant propre, qui ne met pas de déodorant ???

A moins de pouvoir se laver toutes les heures, tu finis quand même, même en ayant pris une douche le matin, à en avoir besoin avant le soir....

Donc, même en acceptant cette (douteuse) analogie, cela ne veut pas dire "pas de commentaires"....

8-)

Voir 40 message(s) de cette discussion en une page