Controle de la qualité d'un code : y'a-t-il de bons softs ?
40 réponses
Qbm
Bonjour tout le monde,
Je cherche un soft (sous licence libre de préférence) qui puisse me
fournir des infos sur la qualité de mon code C++. En java, javancss le
fait très bien, mais en C++ j'y connaîs pas grand chose.
J'ai donc parcouru un peu le net avant de poster ici, mais je n'ai pas
trouvé beaucoup d'avis d'utilisateurs. J'aimerais donc savoir quel(s)
logiciel(s) utilisez vous ?
Personnellement je n'ai pas vraiment compris leur utilité. Donner des chiffres sur un code doit sans doute faire bien dans un rapport ?
Surtout pas. Les mésures ne sont intéressantes que dans la mésure qu'on comprend ce qu'il signifie.
Ca sert surtout a mon avis a se faire une idée de la qualité d'un code qui n'est pas le tiens sans avoir a le lire. Typiquement, quand le chef voit qu'il y a 0.0001% de commentaires dans le code d'un de ses employés, il est en droit de se poser des questions ... Et il n'a pas nécessairement le temps ni la compétence de lire le code lui même.
S'il y a 0.0001% de commentaires dans le code, on peut probablement se poser des questions, mais s'il y en a 99.999%, je pense que l'on peut s'en poser encore plus !!!
Je n'ai jamais vu une mésure de complexité qui prenait en compte le pourcentage des commentaires. Mais comme tu dis, dans l'ensemble, les extrèmes sont inquiètants. Plus important, peut-être, c'est que le pourcentage dans les .cc pourrait bien être différent que dans les .hh -- dans les .hh, je crois que je tourne à environ 50% commentaire ; dans les .cc, prèsque rien. (Mais ce qui est bon depend aussi des conventions de documentation de la boîte -- si on écrit une documentation interface à part, je m'attendrais à bien moins de commentaire dans les .hh que si on se sert de Doxygen.)
Comme divers autres intervenants, je ne vois pas en quoi ce genre de statistiques peut donner une mesure de qualité intrinseque sur du code.
Elle ne mésure pas la qualité intrinséque. Elle donne des indications utiles, c'est tout. Donc, si ton code a une mésure de compléxité d'environ 10, tu sais qu'il y aurait probablement des problèmes, à moins qu'il s'agit d'un des cas connu où la mésure de complexité trompe (surtout, des fonctions de type scanner qui ne comporte qu'un énorme switch).
Par contre je l'imagine tres bien dans une optique de comparaison entre projets.
Ou de comparaison entre modules à l'intérieur d'un seul projet.
Dans certains cas, un ratio entre le nombre de lignes de code et le nombre de personnes affectées sur ce code pourrait me sembler pertinent pour déterminer si les moyens sont bien répartis par rapport aux besoins (en supposant bien sur que ce ne soit qu'un indicateur parmi d'autres...)
D'après mon expérience, il y a une forte corrélation entre la mésure de complexité et le coût de maintenance du code. D'autres ont eu la même expérience.
-- James Kanze GABI Software http://www.gabi-soft.fr 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
Olivier Azeau wrote:
Matthieu Moy wrote:
Richard Delorme <abulmo@nospam.fr> writes:
Personnellement je n'ai pas vraiment compris leur
utilité. Donner des chiffres sur un code doit sans doute
faire bien dans un rapport ?
Surtout pas. Les mésures ne sont intéressantes que dans la
mésure qu'on comprend ce qu'il signifie.
Ca sert surtout a mon avis a se faire une idée de la qualité
d'un code qui n'est pas le tiens sans avoir a le
lire. Typiquement, quand le chef voit qu'il y a 0.0001% de
commentaires dans le code d'un de ses employés, il est en
droit de se poser des questions ... Et il n'a pas
nécessairement le temps ni la compétence de lire le code lui
même.
S'il y a 0.0001% de commentaires dans le code, on peut
probablement se poser des questions, mais s'il y en a 99.999%,
je pense que l'on peut s'en poser encore plus !!!
Je n'ai jamais vu une mésure de complexité qui prenait en compte
le pourcentage des commentaires. Mais comme tu dis, dans
l'ensemble, les extrèmes sont inquiètants. Plus important,
peut-être, c'est que le pourcentage dans les .cc pourrait bien
être différent que dans les .hh -- dans les .hh, je crois que je
tourne à environ 50% commentaire ; dans les .cc, prèsque
rien. (Mais ce qui est bon depend aussi des conventions de
documentation de la boîte -- si on écrit une documentation
interface à part, je m'attendrais à bien moins de commentaire
dans les .hh que si on se sert de Doxygen.)
Comme divers autres intervenants, je ne vois pas en quoi ce
genre de statistiques peut donner une mesure de qualité
intrinseque sur du code.
Elle ne mésure pas la qualité intrinséque. Elle donne des
indications utiles, c'est tout. Donc, si ton code a une mésure
de compléxité d'environ 10, tu sais qu'il y aurait probablement
des problèmes, à moins qu'il s'agit d'un des cas connu où la
mésure de complexité trompe (surtout, des fonctions de type
scanner qui ne comporte qu'un énorme switch).
Par contre je l'imagine tres bien dans une optique de
comparaison entre projets.
Ou de comparaison entre modules à l'intérieur d'un seul projet.
Dans certains cas, un ratio entre le nombre de lignes de code
et le nombre de personnes affectées sur ce code pourrait me
sembler pertinent pour déterminer si les moyens sont bien
répartis par rapport aux besoins (en supposant bien sur que ce
ne soit qu'un indicateur parmi d'autres...)
D'après mon expérience, il y a une forte corrélation entre la
mésure de complexité et le coût de maintenance du code. D'autres
ont eu la même expérience.
--
James Kanze GABI Software http://www.gabi-soft.fr
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
Personnellement je n'ai pas vraiment compris leur utilité. Donner des chiffres sur un code doit sans doute faire bien dans un rapport ?
Surtout pas. Les mésures ne sont intéressantes que dans la mésure qu'on comprend ce qu'il signifie.
Ca sert surtout a mon avis a se faire une idée de la qualité d'un code qui n'est pas le tiens sans avoir a le lire. Typiquement, quand le chef voit qu'il y a 0.0001% de commentaires dans le code d'un de ses employés, il est en droit de se poser des questions ... Et il n'a pas nécessairement le temps ni la compétence de lire le code lui même.
S'il y a 0.0001% de commentaires dans le code, on peut probablement se poser des questions, mais s'il y en a 99.999%, je pense que l'on peut s'en poser encore plus !!!
Je n'ai jamais vu une mésure de complexité qui prenait en compte le pourcentage des commentaires. Mais comme tu dis, dans l'ensemble, les extrèmes sont inquiètants. Plus important, peut-être, c'est que le pourcentage dans les .cc pourrait bien être différent que dans les .hh -- dans les .hh, je crois que je tourne à environ 50% commentaire ; dans les .cc, prèsque rien. (Mais ce qui est bon depend aussi des conventions de documentation de la boîte -- si on écrit une documentation interface à part, je m'attendrais à bien moins de commentaire dans les .hh que si on se sert de Doxygen.)
Comme divers autres intervenants, je ne vois pas en quoi ce genre de statistiques peut donner une mesure de qualité intrinseque sur du code.
Elle ne mésure pas la qualité intrinséque. Elle donne des indications utiles, c'est tout. Donc, si ton code a une mésure de compléxité d'environ 10, tu sais qu'il y aurait probablement des problèmes, à moins qu'il s'agit d'un des cas connu où la mésure de complexité trompe (surtout, des fonctions de type scanner qui ne comporte qu'un énorme switch).
Par contre je l'imagine tres bien dans une optique de comparaison entre projets.
Ou de comparaison entre modules à l'intérieur d'un seul projet.
Dans certains cas, un ratio entre le nombre de lignes de code et le nombre de personnes affectées sur ce code pourrait me sembler pertinent pour déterminer si les moyens sont bien répartis par rapport aux besoins (en supposant bien sur que ce ne soit qu'un indicateur parmi d'autres...)
D'après mon expérience, il y a une forte corrélation entre la mésure de complexité et le coût de maintenance du code. D'autres ont eu la même expérience.
-- James Kanze GABI Software http://www.gabi-soft.fr 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
Fabien LE LEZ
On Mon, 24 Jan 2005 06:14:17 +0100, "" :
gprog [gprof]
A quoi sert-il exactement dans ce cas précis ? Il me semble que gprof est un profiler, i.e. un programme qui permet de savoir où optimiser le code (ce qui peut vouloir dire sacrifier la lisibilité pour accélérer l'exécution).
Quant à memprof (détecteur de fuites mémoires si j'ai bien compris), je serais presque tenté de dire que si on ressent le besoin d'un tel outil, c'est que le code est mauvais.
-- ;-)
On Mon, 24 Jan 2005 06:14:17 +0100, "noone@nowhere.com"
<noone@nowhere.com>:
gprog
[gprof]
A quoi sert-il exactement dans ce cas précis ?
Il me semble que gprof est un profiler, i.e. un programme qui permet
de savoir où optimiser le code (ce qui peut vouloir dire sacrifier la
lisibilité pour accélérer l'exécution).
Quant à memprof (détecteur de fuites mémoires si j'ai bien compris),
je serais presque tenté de dire que si on ressent le besoin d'un tel
outil, c'est que le code est mauvais.
A quoi sert-il exactement dans ce cas précis ? Il me semble que gprof est un profiler, i.e. un programme qui permet de savoir où optimiser le code (ce qui peut vouloir dire sacrifier la lisibilité pour accélérer l'exécution).
Quant à memprof (détecteur de fuites mémoires si j'ai bien compris), je serais presque tenté de dire que si on ressent le besoin d'un tel outil, c'est que le code est mauvais.
-- ;-)
Olivier Azeau
Fabien LE LEZ wrote:
On Mon, 24 Jan 2005 06:14:17 +0100, "" :
gprog [gprof]
A quoi sert-il exactement dans ce cas précis ? Il me semble que gprof est un profiler, i.e. un programme qui permet de savoir où optimiser le code (ce qui peut vouloir dire sacrifier la
lisibilité pour accélérer l'exécution).
Tu veux dire que la vitesse d'exécution ne peut pas etre un bon critere de qualité ?
Quant à memprof (détecteur de fuites mémoires si j'ai bien compris),
je serais presque tenté de dire que si on ressent le besoin d'un tel outil, c'est que le code est mauvais.
Moi je serais tenté de dire que tant qu'on n'a pas passé un tel outil sur un code, on ne peut pas savoir si ce code en a besoin...
Fabien LE LEZ wrote:
On Mon, 24 Jan 2005 06:14:17 +0100, "noone@nowhere.com"
<noone@nowhere.com>:
gprog
[gprof]
A quoi sert-il exactement dans ce cas précis ?
Il me semble que gprof est un profiler, i.e. un programme qui permet
de savoir où optimiser le code (ce qui peut vouloir dire sacrifier
la
lisibilité pour accélérer l'exécution).
Tu veux dire que la vitesse d'exécution ne peut pas etre un bon
critere de qualité ?
Quant à memprof (détecteur de fuites mémoires si j'ai bien
compris),
je serais presque tenté de dire que si on ressent le besoin d'un tel
outil, c'est que le code est mauvais.
Moi je serais tenté de dire que tant qu'on n'a pas passé un tel outil
sur un code, on ne peut pas savoir si ce code en a besoin...
A quoi sert-il exactement dans ce cas précis ? Il me semble que gprof est un profiler, i.e. un programme qui permet de savoir où optimiser le code (ce qui peut vouloir dire sacrifier la
lisibilité pour accélérer l'exécution).
Tu veux dire que la vitesse d'exécution ne peut pas etre un bon critere de qualité ?
Quant à memprof (détecteur de fuites mémoires si j'ai bien compris),
je serais presque tenté de dire que si on ressent le besoin d'un tel outil, c'est que le code est mauvais.
Moi je serais tenté de dire que tant qu'on n'a pas passé un tel outil sur un code, on ne peut pas savoir si ce code en a besoin...
Matthieu Moy
Fabien LE LEZ writes:
Quant à memprof (détecteur de fuites mémoires si j'ai bien compris), je serais presque tenté de dire que si on ressent le besoin d'un tel outil, c'est que le code est mauvais.
Comme tous les outils de débogage. Quand on n'a pas de bug, on n'en a pas besoin, en effet.
-- Matthieu
Fabien LE LEZ <gramster@gramster.com> writes:
Quant à memprof (détecteur de fuites mémoires si j'ai bien compris),
je serais presque tenté de dire que si on ressent le besoin d'un tel
outil, c'est que le code est mauvais.
Comme tous les outils de débogage. Quand on n'a pas de bug, on n'en a
pas besoin, en effet.
Quant à memprof (détecteur de fuites mémoires si j'ai bien compris), je serais presque tenté de dire que si on ressent le besoin d'un tel outil, c'est que le code est mauvais.
Comme tous les outils de débogage. Quand on n'a pas de bug, on n'en a pas besoin, en effet.
-- Matthieu
Gabriel Dos Reis
writes:
| Olivier Azeau wrote: | > Matthieu Moy wrote: | > > Richard Delorme writes: | | > > > Personnellement je n'ai pas vraiment compris leur | > > > utilité. Donner des chiffres sur un code doit sans doute | > > > faire bien dans un rapport ? | | Surtout pas. Les mésures ne sont intéressantes que dans la | mésure qu'on comprend ce qu'il signifie. | | > > Ca sert surtout a mon avis a se faire une idée de la qualité | > > d'un code qui n'est pas le tiens sans avoir a le | > > lire. Typiquement, quand le chef voit qu'il y a 0.0001% de | > > commentaires dans le code d'un de ses employés, il est en | > > droit de se poser des questions ... Et il n'a pas | > > nécessairement le temps ni la compétence de lire le code lui | > > même. | | > S'il y a 0.0001% de commentaires dans le code, on peut | > probablement se poser des questions, mais s'il y en a 99.999%, | > je pense que l'on peut s'en poser encore plus !!! | | Je n'ai jamais vu une mésure de complexité qui prenait en compte | le pourcentage des commentaires.
Mais cela ne veut pas dire que cela n'existe pas pour autant :-)
-- Gaby
kanze@gabi-soft.fr writes:
| Olivier Azeau wrote:
| > Matthieu Moy wrote:
| > > Richard Delorme <abulmo@nospam.fr> writes:
|
| > > > Personnellement je n'ai pas vraiment compris leur
| > > > utilité. Donner des chiffres sur un code doit sans doute
| > > > faire bien dans un rapport ?
|
| Surtout pas. Les mésures ne sont intéressantes que dans la
| mésure qu'on comprend ce qu'il signifie.
|
| > > Ca sert surtout a mon avis a se faire une idée de la qualité
| > > d'un code qui n'est pas le tiens sans avoir a le
| > > lire. Typiquement, quand le chef voit qu'il y a 0.0001% de
| > > commentaires dans le code d'un de ses employés, il est en
| > > droit de se poser des questions ... Et il n'a pas
| > > nécessairement le temps ni la compétence de lire le code lui
| > > même.
|
| > S'il y a 0.0001% de commentaires dans le code, on peut
| > probablement se poser des questions, mais s'il y en a 99.999%,
| > je pense que l'on peut s'en poser encore plus !!!
|
| Je n'ai jamais vu une mésure de complexité qui prenait en compte
| le pourcentage des commentaires.
Mais cela ne veut pas dire que cela n'existe pas pour autant :-)
| Olivier Azeau wrote: | > Matthieu Moy wrote: | > > Richard Delorme writes: | | > > > Personnellement je n'ai pas vraiment compris leur | > > > utilité. Donner des chiffres sur un code doit sans doute | > > > faire bien dans un rapport ? | | Surtout pas. Les mésures ne sont intéressantes que dans la | mésure qu'on comprend ce qu'il signifie. | | > > Ca sert surtout a mon avis a se faire une idée de la qualité | > > d'un code qui n'est pas le tiens sans avoir a le | > > lire. Typiquement, quand le chef voit qu'il y a 0.0001% de | > > commentaires dans le code d'un de ses employés, il est en | > > droit de se poser des questions ... Et il n'a pas | > > nécessairement le temps ni la compétence de lire le code lui | > > même. | | > S'il y a 0.0001% de commentaires dans le code, on peut | > probablement se poser des questions, mais s'il y en a 99.999%, | > je pense que l'on peut s'en poser encore plus !!! | | Je n'ai jamais vu une mésure de complexité qui prenait en compte | le pourcentage des commentaires.
Mais cela ne veut pas dire que cela n'existe pas pour autant :-)
-- Gaby
Loïc Joly
Olivier Azeau wrote:
Comme divers autres intervenants, je ne vois pas en quoi ce genre de statistiques peut donner une mesure de qualité intrinseque sur du code.
Dans du vrai code, au boulot, ce genre de mesure a permi d'identifier une classe définie en plusieurs milliers de lignes, avec plusieurs fonctions de plus de 2000 lignes (certaines de 10000 je crois), une complexité cyclotomatique de l'ordre de 100 dans pas mal de fonctions. Eh bien, je trouve que ces chiffres indiquent un problème, et qu'ils peuvent servir à trois choses :
- Quand on doit prendre en main un code fait par d'autres, avoir une idée de l'étendue des dégats, afin d'évaluer rapidement le temps de prise en main qui sera nécessaire.
- Servir d'argument massue lors d'une recette (pour du code fait en externe). Il est en effet difficile de spécifier dans un cahier des charges qu'on veut du beau code, car c'est sujet à goûts et débats d'idée (à moins peut-être de définir un organisme externe aux deux parties chargé d'arbitrer). Spécifier de tels éléments de mesure certes ne garanti en rien la qualité du résultat, mais permet d'éliminer un type de non qualité, et c'est toujours ça de pris.
- Si on remarque que sur plusieurs projets du même type, on trouve pour une équipe des corrélations entre divers paramètres, ça peut être une voie de progrès pour cette équipe (par exemple, si le ratio entre complexité d'une fontion et nombre de bugs trouvé dedans est constant, c'est une bonne motivation pour inciter une équipe à diminuer la complexité de ses fonctions).
-- Loïc
Olivier Azeau wrote:
Comme divers autres intervenants, je ne vois pas en quoi ce genre de
statistiques peut donner une mesure de qualité intrinseque sur du
code.
Dans du vrai code, au boulot, ce genre de mesure a permi d'identifier
une classe définie en plusieurs milliers de lignes, avec plusieurs
fonctions de plus de 2000 lignes (certaines de 10000 je crois), une
complexité cyclotomatique de l'ordre de 100 dans pas mal de fonctions.
Eh bien, je trouve que ces chiffres indiquent un problème, et qu'ils
peuvent servir à trois choses :
- Quand on doit prendre en main un code fait par d'autres, avoir une
idée de l'étendue des dégats, afin d'évaluer rapidement le temps de
prise en main qui sera nécessaire.
- Servir d'argument massue lors d'une recette (pour du code fait en
externe). Il est en effet difficile de spécifier dans un cahier des
charges qu'on veut du beau code, car c'est sujet à goûts et débats
d'idée (à moins peut-être de définir un organisme externe aux deux
parties chargé d'arbitrer). Spécifier de tels éléments de mesure certes
ne garanti en rien la qualité du résultat, mais permet d'éliminer un
type de non qualité, et c'est toujours ça de pris.
- Si on remarque que sur plusieurs projets du même type, on trouve pour
une équipe des corrélations entre divers paramètres, ça peut être une
voie de progrès pour cette équipe (par exemple, si le ratio entre
complexité d'une fontion et nombre de bugs trouvé dedans est constant,
c'est une bonne motivation pour inciter une équipe à diminuer la
complexité de ses fonctions).
Comme divers autres intervenants, je ne vois pas en quoi ce genre de statistiques peut donner une mesure de qualité intrinseque sur du code.
Dans du vrai code, au boulot, ce genre de mesure a permi d'identifier une classe définie en plusieurs milliers de lignes, avec plusieurs fonctions de plus de 2000 lignes (certaines de 10000 je crois), une complexité cyclotomatique de l'ordre de 100 dans pas mal de fonctions. Eh bien, je trouve que ces chiffres indiquent un problème, et qu'ils peuvent servir à trois choses :
- Quand on doit prendre en main un code fait par d'autres, avoir une idée de l'étendue des dégats, afin d'évaluer rapidement le temps de prise en main qui sera nécessaire.
- Servir d'argument massue lors d'une recette (pour du code fait en externe). Il est en effet difficile de spécifier dans un cahier des charges qu'on veut du beau code, car c'est sujet à goûts et débats d'idée (à moins peut-être de définir un organisme externe aux deux parties chargé d'arbitrer). Spécifier de tels éléments de mesure certes ne garanti en rien la qualité du résultat, mais permet d'éliminer un type de non qualité, et c'est toujours ça de pris.
- Si on remarque que sur plusieurs projets du même type, on trouve pour une équipe des corrélations entre divers paramètres, ça peut être une voie de progrès pour cette équipe (par exemple, si le ratio entre complexité d'une fontion et nombre de bugs trouvé dedans est constant, c'est une bonne motivation pour inciter une équipe à diminuer la complexité de ses fonctions).
-- Loïc
Loïc Joly
Olivier Azeau wrote:
Fabien LE LEZ wrote:
On Mon, 24 Jan 2005 06:14:17 +0100, "" :
gprog
[gprof]
A quoi sert-il exactement dans ce cas précis ? Il me semble que gprof est un profiler, i.e. un programme qui permet de savoir où optimiser le code (ce qui peut vouloir dire sacrifier
la
lisibilité pour accélérer l'exécution).
Tu veux dire que la vitesse d'exécution ne peut pas etre un bon critere de qualité ?
Je dirais ue la vitesse d'exécution du code vue par un utilisateur au sens large peut être un bon critère que qualité. Mais ce n'est pas ce que mesure un profiler. Un profiler a pour but de localiser les bottleneck, en faisant des mesures d'une granularité bien plus faible que le niveau de qualité requis. Donc je dirais qu'un profiler n'est pas un outil de *mesure* du critère de qualité "temps d'exécution", mais un outil qui permet d'obtenir un temps d'exécution conforme à celui requis.
-- Loïc
Olivier Azeau wrote:
Fabien LE LEZ wrote:
On Mon, 24 Jan 2005 06:14:17 +0100, "noone@nowhere.com"
<noone@nowhere.com>:
gprog
[gprof]
A quoi sert-il exactement dans ce cas précis ?
Il me semble que gprof est un profiler, i.e. un programme qui permet
de savoir où optimiser le code (ce qui peut vouloir dire sacrifier
la
lisibilité pour accélérer l'exécution).
Tu veux dire que la vitesse d'exécution ne peut pas etre un bon
critere de qualité ?
Je dirais ue la vitesse d'exécution du code vue par un utilisateur au
sens large peut être un bon critère que qualité. Mais ce n'est pas ce
que mesure un profiler. Un profiler a pour but de localiser les
bottleneck, en faisant des mesures d'une granularité bien plus faible
que le niveau de qualité requis. Donc je dirais qu'un profiler n'est pas
un outil de *mesure* du critère de qualité "temps d'exécution", mais un
outil qui permet d'obtenir un temps d'exécution conforme à celui requis.
A quoi sert-il exactement dans ce cas précis ? Il me semble que gprof est un profiler, i.e. un programme qui permet de savoir où optimiser le code (ce qui peut vouloir dire sacrifier
la
lisibilité pour accélérer l'exécution).
Tu veux dire que la vitesse d'exécution ne peut pas etre un bon critere de qualité ?
Je dirais ue la vitesse d'exécution du code vue par un utilisateur au sens large peut être un bon critère que qualité. Mais ce n'est pas ce que mesure un profiler. Un profiler a pour but de localiser les bottleneck, en faisant des mesures d'une granularité bien plus faible que le niveau de qualité requis. Donc je dirais qu'un profiler n'est pas un outil de *mesure* du critère de qualité "temps d'exécution", mais un outil qui permet d'obtenir un temps d'exécution conforme à celui requis.
-- Loïc
Matthieu Moy
Olivier Azeau writes:
Et personne travaillant sur ce code n'avait identifié le problème sans outil ? j'en doute...
La situation décrite est, en carricaturant un peu : « du code écrit par des incompétents repris ou évalué par des gens compétents ». Ce genre de cas est AMHA assez fréquent ... Les outils ne changeront pas forcément les premiers, mais ils feront gagner du temps aux seconds.
Et personne travaillant sur ce code n'avait identifié le problème sans
outil ? j'en doute...
La situation décrite est, en carricaturant un peu : « du code écrit
par des incompétents repris ou évalué par des gens compétents ». Ce
genre de cas est AMHA assez fréquent ... Les outils ne changeront pas
forcément les premiers, mais ils feront gagner du temps aux seconds.
Et personne travaillant sur ce code n'avait identifié le problème sans outil ? j'en doute...
La situation décrite est, en carricaturant un peu : « du code écrit par des incompétents repris ou évalué par des gens compétents ». Ce genre de cas est AMHA assez fréquent ... Les outils ne changeront pas forcément les premiers, mais ils feront gagner du temps aux seconds.
-- Matthieu
Olivier Azeau
Loïc Joly wrote:
Dans du vrai code, au boulot, ce genre de mesure a permi d'identifier une classe définie en plusieurs milliers de lignes, avec plusieurs fonctions de plus de 2000 lignes (certaines de 10000 je crois), une complexité cyclotomatique de l'ordre de 100 dans pas mal de fonctions. Eh bien, je trouve que ces chiffres indiquent un problème, et qu'ils peuvent servir à trois choses :
Et personne travaillant sur ce code n'avait identifié le problème sans outil ? j'en doute...
Loïc Joly wrote:
Dans du vrai code, au boulot, ce genre de mesure a permi d'identifier
une classe définie en plusieurs milliers de lignes, avec plusieurs
fonctions de plus de 2000 lignes (certaines de 10000 je crois), une
complexité cyclotomatique de l'ordre de 100 dans pas mal de fonctions.
Eh bien, je trouve que ces chiffres indiquent un problème, et qu'ils
peuvent servir à trois choses :
Et personne travaillant sur ce code n'avait identifié le problème sans
outil ? j'en doute...
Dans du vrai code, au boulot, ce genre de mesure a permi d'identifier une classe définie en plusieurs milliers de lignes, avec plusieurs fonctions de plus de 2000 lignes (certaines de 10000 je crois), une complexité cyclotomatique de l'ordre de 100 dans pas mal de fonctions. Eh bien, je trouve que ces chiffres indiquent un problème, et qu'ils peuvent servir à trois choses :
Et personne travaillant sur ce code n'avait identifié le problème sans outil ? j'en doute...
Fabien LE LEZ
On Tue, 25 Jan 2005 21:44:47 +0100, Loïc Joly :
Je dirais ue la vitesse d'exécution du code vue par un utilisateur au sens large peut être un bon critère de qualité.
Et encore, critère de qualité de l'application dans son ensemble, pas vraiment qualité du code (i.e. lisibilité, simplicité, facilité d'évolution, etc.)
-- ;-)
On Tue, 25 Jan 2005 21:44:47 +0100, Loïc Joly
<loic.actarus.joly@wanadoo.fr>:
Je dirais ue la vitesse d'exécution du code vue par un utilisateur au
sens large peut être un bon critère de qualité.
Et encore, critère de qualité de l'application dans son ensemble, pas
vraiment qualité du code (i.e. lisibilité, simplicité, facilité
d'évolution, etc.)
Je dirais ue la vitesse d'exécution du code vue par un utilisateur au sens large peut être un bon critère de qualité.
Et encore, critère de qualité de l'application dans son ensemble, pas vraiment qualité du code (i.e. lisibilité, simplicité, facilité d'évolution, etc.)
