Bonjour à tous
Je voudrais savoir s'il existe un petit programme permettant, à partir d'un
ensemble de fichiers sources, de calculer quelques statistiques telles que:
- nombre de lignes total
- nombre de lignes de codes
- nombre de lignes de commentaires
- nombre de lignes vides
"Aurelien Regat-Barrel" a écrit dans le message de news: 43156d13$0$31029$
Juste une question : Quel est l'intérêt de ce genre de stats ?
Y'a eu un article là dessus dans CUJ je crois (avec SourceMonitor comme exemple). Apparement, dans certaines boites, le pourcentage de commentaires, le nombre de fonctions membres par classe, etc... sont des critères de rejet de code.
-- Aurélien Regat-Barrel
Cela ne me semble pas raisonnable. Certaines boîtes adopte une méthode bien plus constructive et productive : Par exemple, dans une équipe de développeurs, l'audit du code est effectué par un autre membre de l'équipe et réciproquement.
-- -Stan
"Aurelien Regat-Barrel" <nospam.aregatba@yahoo.fr> a écrit dans le message
de news: 43156d13$0$31029$626a14ce@news.free.fr...
Juste une question : Quel est l'intérêt de ce genre de stats ?
Y'a eu un article là dessus dans CUJ je crois (avec SourceMonitor comme
exemple).
Apparement, dans certaines boites, le pourcentage de commentaires, le
nombre de fonctions membres par classe, etc... sont des critères de rejet
de code.
--
Aurélien Regat-Barrel
Cela ne me semble pas raisonnable.
Certaines boîtes adopte une méthode bien plus constructive et productive :
Par exemple, dans une équipe de développeurs, l'audit du code est effectué
par un autre
membre de l'équipe et réciproquement.
"Aurelien Regat-Barrel" a écrit dans le message de news: 43156d13$0$31029$
Juste une question : Quel est l'intérêt de ce genre de stats ?
Y'a eu un article là dessus dans CUJ je crois (avec SourceMonitor comme exemple). Apparement, dans certaines boites, le pourcentage de commentaires, le nombre de fonctions membres par classe, etc... sont des critères de rejet de code.
-- Aurélien Regat-Barrel
Cela ne me semble pas raisonnable. Certaines boîtes adopte une méthode bien plus constructive et productive : Par exemple, dans une équipe de développeurs, l'audit du code est effectué par un autre membre de l'équipe et réciproquement.
-- -Stan
Stan
De: "Loïc Joly"
Je suis pas 100% d'accord, même s'il y a parfois de ça. Elle peuvent
Moi je suis à 100% d'accord avec moi ;-)
Autre exemple : Le projet A, semblable à celui ci, a demandé m1 mois pour n1 lignes de codes. On en est actuellement à m2 mois pour n2 lignes, est-ce qu'on s'améliore.
C'est justement l'exemple qu'il ne fallait pas donner. A une époque on gratifiait un programmeur aux nombre de lignes qu'il pouvait "pondre", aujourd'hui, la tendance est inversé.
De plus la méthode de la comparaison est rarement appliquable.
Sans mesure, d'une forme ou d'une autre, comment savoir si l'on progresse.
Malheuresement ( ou heureusement ), certaines choses ne sont pas mesurables ou quantifiables. Rien ne vaut l'expertise humaine et
Bien entendu, comme tout outil, il faut l'utiliser à bon escient.
dans la pluspart des cas, les outils de ce genre ne sont finalement pas très utiles.
-- -Stan
De: "Loïc Joly" <loic.actarus.joly@wanadoo.fr>
Je suis pas 100% d'accord, même s'il y a parfois de ça. Elle peuvent
Moi je suis à 100% d'accord avec moi ;-)
Autre exemple : Le projet A, semblable à celui ci, a demandé m1 mois pour
n1 lignes de codes. On en est actuellement à m2 mois pour n2 lignes,
est-ce qu'on s'améliore.
C'est justement l'exemple qu'il ne fallait pas donner.
A une époque on gratifiait un programmeur aux nombre de lignes
qu'il pouvait "pondre", aujourd'hui, la tendance est inversé.
De plus la méthode de la comparaison est rarement appliquable.
Sans mesure, d'une forme ou d'une autre, comment savoir si l'on
progresse.
Malheuresement ( ou heureusement ), certaines choses ne sont pas mesurables
ou quantifiables.
Rien ne vaut l'expertise humaine et
Bien entendu, comme tout outil, il faut l'utiliser à bon escient.
dans la pluspart des cas, les outils de ce genre ne sont finalement pas
très utiles.
Je suis pas 100% d'accord, même s'il y a parfois de ça. Elle peuvent
Moi je suis à 100% d'accord avec moi ;-)
Autre exemple : Le projet A, semblable à celui ci, a demandé m1 mois pour n1 lignes de codes. On en est actuellement à m2 mois pour n2 lignes, est-ce qu'on s'améliore.
C'est justement l'exemple qu'il ne fallait pas donner. A une époque on gratifiait un programmeur aux nombre de lignes qu'il pouvait "pondre", aujourd'hui, la tendance est inversé.
De plus la méthode de la comparaison est rarement appliquable.
Sans mesure, d'une forme ou d'une autre, comment savoir si l'on progresse.
Malheuresement ( ou heureusement ), certaines choses ne sont pas mesurables ou quantifiables. Rien ne vaut l'expertise humaine et
Bien entendu, comme tout outil, il faut l'utiliser à bon escient.
dans la pluspart des cas, les outils de ce genre ne sont finalement pas très utiles.
-- -Stan
plouf
n s'améliore.
C'est justement l'exemple qu'il ne fallait pas donner. A une époque on gratifiait un programmeur aux nombre de lignes qu'il pouvait "pondre", aujourd'hui, la tendance est inversé.
Heureusement, car c'était sûrement le meilleur moyen d'avoir des programmes remplis de "copié-collés" avec des bugs qui doivent être corrigés 50 fois.
n s'améliore.
C'est justement l'exemple qu'il ne fallait pas donner.
A une époque on gratifiait un programmeur aux nombre de lignes
qu'il pouvait "pondre", aujourd'hui, la tendance est inversé.
Heureusement, car c'était sûrement le meilleur moyen d'avoir des
programmes remplis de "copié-collés" avec des bugs qui doivent
être corrigés 50 fois.
C'est justement l'exemple qu'il ne fallait pas donner. A une époque on gratifiait un programmeur aux nombre de lignes qu'il pouvait "pondre", aujourd'hui, la tendance est inversé.
Heureusement, car c'était sûrement le meilleur moyen d'avoir des programmes remplis de "copié-collés" avec des bugs qui doivent être corrigés 50 fois.
Zlika
Ben justement, mon intéret c'est de montrer au chef que j'ai pu refondre un programme de 33000 lignes codés avec les pieds en 7000 lignes propres!
"plouf" a écrit dans le message de news: q2pRe.28972$
n s'améliore.
C'est justement l'exemple qu'il ne fallait pas donner. A une époque on gratifiait un programmeur aux nombre de lignes qu'il pouvait "pondre", aujourd'hui, la tendance est inversé.
Heureusement, car c'était sûrement le meilleur moyen d'avoir des programmes remplis de "copié-collés" avec des bugs qui doivent être corrigés 50 fois.
Ben justement, mon intéret c'est de montrer au chef que j'ai pu refondre un
programme de 33000 lignes codés avec les pieds en 7000 lignes propres!
"plouf" <plouf79@yahoo.fr> a écrit dans le message de news:
q2pRe.28972$hV3.11830@nntpserver.swip.net...
n s'améliore.
C'est justement l'exemple qu'il ne fallait pas donner.
A une époque on gratifiait un programmeur aux nombre de lignes
qu'il pouvait "pondre", aujourd'hui, la tendance est inversé.
Heureusement, car c'était sûrement le meilleur moyen d'avoir des
programmes remplis de "copié-collés" avec des bugs qui doivent
être corrigés 50 fois.
Ben justement, mon intéret c'est de montrer au chef que j'ai pu refondre un programme de 33000 lignes codés avec les pieds en 7000 lignes propres!
"plouf" a écrit dans le message de news: q2pRe.28972$
n s'améliore.
C'est justement l'exemple qu'il ne fallait pas donner. A une époque on gratifiait un programmeur aux nombre de lignes qu'il pouvait "pondre", aujourd'hui, la tendance est inversé.
Heureusement, car c'était sûrement le meilleur moyen d'avoir des programmes remplis de "copié-collés" avec des bugs qui doivent être corrigés 50 fois.
kanze
Stan ( remove the dots ) wrote:
De: "Loïc Joly"
Je suis pas 100% d'accord, même s'il y a parfois de ça. Elle peuvent
Moi je suis à 100% d'accord avec moi ;-)
Autre exemple : Le projet A, semblable à celui ci, a demandé m1 mois pour n1 lignes de codes. On en est actuellement à m2 mois pour n2 lignes, est-ce qu'on s'améliore.
C'est justement l'exemple qu'il ne fallait pas donner. A une époque on gratifiait un programmeur aux nombre de lignes qu'il pouvait "pondre", aujourd'hui, la tendance est inversé.
Ça dépend. Si on introduit un nouvel outil ou un changement dans le processus de développement, il faut bien mesurer si la productivité du programmeur a augmenté. Et jusqu'à ce qu'on trouve quelque chose de mieux, une des mesures du productivite des programmeurs, c'est bien le nombre de lignes de code qu'il produit. (Évidemment, il faut contrôler les autres variables aussi. Quand on compare le nombre de lignes avant et après, il faut s'assurer que la qualité du code est le même aussi, que c'est aussi bien documenté, etc.)
De plus la méthode de la comparaison est rarement appliquable.
Tu en as une meilleur ?
Sans mesure, d'une forme ou d'une autre, comment savoir si l'on progresse.
Malheuresement ( ou heureusement ), certaines choses ne sont pas mesurables ou quantifiables.
Peut-être, mais la productivité des programmeurs n'en est pas une.
En fait, c'est rarement aussi noir et blanc. On mesure avec plus ou moins de précision.
Rien ne vaut l'expertise humaine et
Bien entendu, comme tout outil, il faut l'utiliser à bon escient.
dans la pluspart des cas, les outils de ce genre ne sont finalement pas très utiles.
Ce n'est pas ce que disent les experts. Au contraire, des outils de mesure sont essentiels si tu veux produire du logiciel de qualité, à un prix prévisible.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Stan ( remove the dots ) wrote:
De: "Loïc Joly" <loic.actarus.joly@wanadoo.fr>
Je suis pas 100% d'accord, même s'il y a parfois de ça.
Elle peuvent
Moi je suis à 100% d'accord avec moi ;-)
Autre exemple : Le projet A, semblable à celui ci, a
demandé m1 mois pour n1 lignes de codes. On en est
actuellement à m2 mois pour n2 lignes, est-ce qu'on
s'améliore.
C'est justement l'exemple qu'il ne fallait pas donner. A une
époque on gratifiait un programmeur aux nombre de lignes qu'il
pouvait "pondre", aujourd'hui, la tendance est inversé.
Ça dépend. Si on introduit un nouvel outil ou un changement dans
le processus de développement, il faut bien mesurer si la
productivité du programmeur a augmenté. Et jusqu'à ce qu'on
trouve quelque chose de mieux, une des mesures du productivite
des programmeurs, c'est bien le nombre de lignes de code qu'il
produit. (Évidemment, il faut contrôler les autres variables
aussi. Quand on compare le nombre de lignes avant et après, il
faut s'assurer que la qualité du code est le même aussi, que
c'est aussi bien documenté, etc.)
De plus la méthode de la comparaison est rarement appliquable.
Tu en as une meilleur ?
Sans mesure, d'une forme ou d'une autre, comment savoir si
l'on progresse.
Malheuresement ( ou heureusement ), certaines choses ne sont
pas mesurables ou quantifiables.
Peut-être, mais la productivité des programmeurs n'en est pas
une.
En fait, c'est rarement aussi noir et blanc. On mesure avec plus
ou moins de précision.
Rien ne vaut l'expertise humaine et
Bien entendu, comme tout outil, il faut l'utiliser à bon
escient.
dans la pluspart des cas, les outils de ce genre ne sont
finalement pas très utiles.
Ce n'est pas ce que disent les experts. Au contraire, des outils
de mesure sont essentiels si tu veux produire du logiciel de
qualité, à un prix prévisible.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Je suis pas 100% d'accord, même s'il y a parfois de ça. Elle peuvent
Moi je suis à 100% d'accord avec moi ;-)
Autre exemple : Le projet A, semblable à celui ci, a demandé m1 mois pour n1 lignes de codes. On en est actuellement à m2 mois pour n2 lignes, est-ce qu'on s'améliore.
C'est justement l'exemple qu'il ne fallait pas donner. A une époque on gratifiait un programmeur aux nombre de lignes qu'il pouvait "pondre", aujourd'hui, la tendance est inversé.
Ça dépend. Si on introduit un nouvel outil ou un changement dans le processus de développement, il faut bien mesurer si la productivité du programmeur a augmenté. Et jusqu'à ce qu'on trouve quelque chose de mieux, une des mesures du productivite des programmeurs, c'est bien le nombre de lignes de code qu'il produit. (Évidemment, il faut contrôler les autres variables aussi. Quand on compare le nombre de lignes avant et après, il faut s'assurer que la qualité du code est le même aussi, que c'est aussi bien documenté, etc.)
De plus la méthode de la comparaison est rarement appliquable.
Tu en as une meilleur ?
Sans mesure, d'une forme ou d'une autre, comment savoir si l'on progresse.
Malheuresement ( ou heureusement ), certaines choses ne sont pas mesurables ou quantifiables.
Peut-être, mais la productivité des programmeurs n'en est pas une.
En fait, c'est rarement aussi noir et blanc. On mesure avec plus ou moins de précision.
Rien ne vaut l'expertise humaine et
Bien entendu, comme tout outil, il faut l'utiliser à bon escient.
dans la pluspart des cas, les outils de ce genre ne sont finalement pas très utiles.
Ce n'est pas ce que disent les experts. Au contraire, des outils de mesure sont essentiels si tu veux produire du logiciel de qualité, à un prix prévisible.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
Stan ( remove the dots ) wrote:
"Aurelien Regat-Barrel" a écrit dans le message de news: 43156d13$0$31029$
Juste une question : Quel est l'intérêt de ce genre de stats ?
Y'a eu un article là dessus dans CUJ je crois (avec SourceMonitor comme exemple). Apparement, dans certaines boites, le pourcentage de commentaires, le nombre de fonctions membres par classe, etc... sont des critères de rejet de code.
Cela ne me semble pas raisonnable.
Ça dépend du contexte. Disons que de telles règles sont comme les règles de codage : on a droit à les violer si (mais seulement si) on peut en justifier le besoin. Donc, par exemple, une règle du genre pas plus de quinze lignes de code dans une fonction me semble raisonable, mais on finira bien par accepter plus si la fonction ne contient qu'un switch avec une vingtaine de case.
Certaines boîtes adopte une méthode bien plus constructive et productive : Par exemple, dans une équipe de développeurs, l'audit du code est effectué par un autre membre de l'équipe et réciproquement.
La revue du code est une démarche essentielle. Mais les mesures peuvent faciliter la tâche. Dès que la complixité de McCabe monte, par exemple, je sais qu'il faut prêter particulièrement attention. Il n'est même pas sans intérêt de dire que si la complexité de McCabe dépasse un certain niveau, il faut que le comité qui fait la revue s'exprime explicitement qu'il en a pris connaissance, et que c'est justifié dans ce cas précis.
Même quelque chose d'aussi simple que le nombre de lignes peut être un indicateur : si le nombre de lignes est trop élevé par rapport à la complexité du problème, ou par rapport au temps utilisé par le programmeur, par exemple, ça peut-être une mauvaise signe.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Stan ( remove the dots ) wrote:
"Aurelien Regat-Barrel" <nospam.aregatba@yahoo.fr> a écrit
dans le message de news:
43156d13$0$31029$626a14ce@news.free.fr...
Juste une question : Quel est l'intérêt de ce genre de stats ?
Y'a eu un article là dessus dans CUJ je crois (avec
SourceMonitor comme exemple). Apparement, dans certaines
boites, le pourcentage de commentaires, le nombre de
fonctions membres par classe, etc... sont des critères de
rejet de code.
Cela ne me semble pas raisonnable.
Ça dépend du contexte. Disons que de telles règles sont comme
les règles de codage : on a droit à les violer si (mais
seulement si) on peut en justifier le besoin. Donc, par exemple,
une règle du genre pas plus de quinze lignes de code dans une
fonction me semble raisonable, mais on finira bien par accepter
plus si la fonction ne contient qu'un switch avec une vingtaine
de case.
Certaines boîtes adopte une méthode bien plus constructive et
productive : Par exemple, dans une équipe de développeurs,
l'audit du code est effectué par un autre membre de l'équipe
et réciproquement.
La revue du code est une démarche essentielle. Mais les mesures
peuvent faciliter la tâche. Dès que la complixité de McCabe
monte, par exemple, je sais qu'il faut prêter particulièrement
attention. Il n'est même pas sans intérêt de dire que si la
complexité de McCabe dépasse un certain niveau, il faut que le
comité qui fait la revue s'exprime explicitement qu'il en a pris
connaissance, et que c'est justifié dans ce cas précis.
Même quelque chose d'aussi simple que le nombre de lignes peut
être un indicateur : si le nombre de lignes est trop élevé par
rapport à la complexité du problème, ou par rapport au temps
utilisé par le programmeur, par exemple, ça peut-être une
mauvaise signe.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
"Aurelien Regat-Barrel" a écrit dans le message de news: 43156d13$0$31029$
Juste une question : Quel est l'intérêt de ce genre de stats ?
Y'a eu un article là dessus dans CUJ je crois (avec SourceMonitor comme exemple). Apparement, dans certaines boites, le pourcentage de commentaires, le nombre de fonctions membres par classe, etc... sont des critères de rejet de code.
Cela ne me semble pas raisonnable.
Ça dépend du contexte. Disons que de telles règles sont comme les règles de codage : on a droit à les violer si (mais seulement si) on peut en justifier le besoin. Donc, par exemple, une règle du genre pas plus de quinze lignes de code dans une fonction me semble raisonable, mais on finira bien par accepter plus si la fonction ne contient qu'un switch avec une vingtaine de case.
Certaines boîtes adopte une méthode bien plus constructive et productive : Par exemple, dans une équipe de développeurs, l'audit du code est effectué par un autre membre de l'équipe et réciproquement.
La revue du code est une démarche essentielle. Mais les mesures peuvent faciliter la tâche. Dès que la complixité de McCabe monte, par exemple, je sais qu'il faut prêter particulièrement attention. Il n'est même pas sans intérêt de dire que si la complexité de McCabe dépasse un certain niveau, il faut que le comité qui fait la revue s'exprime explicitement qu'il en a pris connaissance, et que c'est justifié dans ce cas précis.
Même quelque chose d'aussi simple que le nombre de lignes peut être un indicateur : si le nombre de lignes est trop élevé par rapport à la complexité du problème, ou par rapport au temps utilisé par le programmeur, par exemple, ça peut-être une mauvaise signe.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
plouf
....
Ce n'est pas ce que disent les experts. Au contraire, des outils de mesure sont essentiels si tu veux produire du logiciel de qualité, à un prix prévisible.
D'après votre expérience, quelles sont les mesures les plus significatives ? Et que représentent-elles exactement ? (et comment sont-elles calculées ?)
Quelles sont celles qui ne servent pas ?
Si vous avez des liens interessants sur ce sujet, je suis preneur.
....
Ce n'est pas ce que disent les experts.
Au contraire, des outils
de mesure sont essentiels si tu veux produire du logiciel de
qualité, à un prix prévisible.
D'après votre expérience, quelles sont les mesures les
plus significatives ? Et que représentent-elles exactement ?
(et comment sont-elles calculées ?)
Quelles sont celles qui ne servent pas ?
Si vous avez des liens interessants sur ce sujet, je suis
preneur.
Ce n'est pas ce que disent les experts. Au contraire, des outils de mesure sont essentiels si tu veux produire du logiciel de qualité, à un prix prévisible.
D'après votre expérience, quelles sont les mesures les plus significatives ? Et que représentent-elles exactement ? (et comment sont-elles calculées ?)
Quelles sont celles qui ne servent pas ?
Si vous avez des liens interessants sur ce sujet, je suis preneur.
plouf
Ben justement, mon intéret c'est de montrer au chef que j'ai pu refondre un programme de 33000 lignes codés avec les pieds en 7000 lignes propres!
Plus c'est court meilleur c'est.
Ben justement, mon intéret c'est de montrer au chef que j'ai pu refondre un
programme de 33000 lignes codés avec les pieds en 7000 lignes propres!
Dans ce cas, je conseille fortement de supprimer les commentaires et les espaces inutiles (sauts de ligne, identation, ...)
plouf
On Fri, 02 Sep 2005 13:26:41 +0200, plouf :
Plus c'est court meilleur c'est.
Dans ce cas, je conseille fortement de supprimer les commentaires et les espaces inutiles (sauts de ligne, identation, ...) Exactement :-D
Ca me fait penser à un article que j'avais lu qui expliquait que le fait d'introduire un moyen d'évaluation entrainait systèmatiquement des mauvais comportements.
Je viens de le retrouver, le voilà : (C'est de l'anglais) http://www.joelonsoftware.com/news/20020715.html
On Fri, 02 Sep 2005 13:26:41 +0200, plouf <plouf79@yahoo.fr>:
Plus c'est court meilleur c'est.
Dans ce cas, je conseille fortement de supprimer les commentaires et
les espaces inutiles (sauts de ligne, identation, ...)
Exactement :-D
Ca me fait penser à un article que j'avais lu qui expliquait
que le fait d'introduire un moyen d'évaluation entrainait
systèmatiquement des mauvais comportements.
Je viens de le retrouver, le voilà :
(C'est de l'anglais)
http://www.joelonsoftware.com/news/20020715.html
Dans ce cas, je conseille fortement de supprimer les commentaires et les espaces inutiles (sauts de ligne, identation, ...) Exactement :-D
Ca me fait penser à un article que j'avais lu qui expliquait que le fait d'introduire un moyen d'évaluation entrainait systèmatiquement des mauvais comportements.
Je viens de le retrouver, le voilà : (C'est de l'anglais) http://www.joelonsoftware.com/news/20020715.html
