Controle de la qualité d'un code : y'a-t-il de bons softs ?

Matthieu Moy wrote:

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.

Pas d'accord. Ce ne sont pas des outils de déboggage, mais de
vérification et de validation. Et on en a toujours besoin, ne
serait-ce que pour valider la reste du processus.

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

kanze@gabi-soft.fr wrote:

Olivier Azeau wrote:

Fabien LE LEZ wrote:

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é ?

Elle le peut. En général, même, il faut que le programme soit
assez rapide. Il n'y a que la définition de « assez » qui varie.
Mais gprof ne sert pas là -- gprof ne va pas me dire si
l'utilisateur se frustre à cause des temps de réponse, par
exemple, ni si mon serveur est capable de traiter 140 requêtes
par séconde, comme c'est écrit dans le cahier de charge.

Là, je crois que l'on mélange un peu tout car le terme "qualité" peut
effectivement vouloir dire beaucoup de choses.

S'il s'agit de la qualité perçue par l'utilisateur, il y a effectivement
de nombreux cas où l'on se retrouve à écrire un outil ad hoc ou à
utiliser des outils d'automatisation (d'envoi de requêtes à un serveur,
d'envoi d'évènements à une IHM, ...) qui n'ont rien à voir avec du
profiling.

Mais la "qualité" du code ça peut aussi être :
- ne pas utiliser à outrance l'allocation dynamique
- ne pas faire des copies inutiles de données
- bien utiliser des composants tiers gourmands en CPU
- ...
J'ai déjà rencontré ces 3 cas et, à chaque fois, la détection du
problème a été faite avec un outil de profiling.

Olivier Azeau wrote:

kanze@gabi-soft.fr wrote:

Olivier Azeau wrote:

Fabien LE LEZ wrote:

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é ?

Elle le peut. En général, même, il faut que le programme
soit assez rapide. Il n'y a que la définition de « assez »
qui varie. Mais gprof ne sert pas là -- gprof ne va pas me
dire si l'utilisateur se frustre à cause des temps de
réponse, par exemple, ni si mon serveur est capable de
traiter 140 requêtes par séconde, comme c'est écrit dans le
cahier de charge.

Là, je crois que l'on mélange un peu tout car le terme
"qualité" peut effectivement vouloir dire beaucoup de choses.

Pas vraiment. Il y a des nuances, mais à la fin, la qualité,
c'est quelque chose qui se sent, à deux niveaux : 1) quoique
fasse l'utilisateur et l'environement, le programme se comporte
comme il faut, selon le cahier de charges, et 2) le programme se
maintient, on peut réparer les entorses à la qualité facilement,
et même facilement le modifier pour y ajouter des
fonctionnalités. La qualité est nécessaire. Mais évidemment, on
veut l'avoir au plus bas prix.

Toute la reste est du bla, bla.

S'il s'agit de la qualité perçue par l'utilisateur, il y a
effectivement de nombreux cas où l'on se retrouve à écrire un
outil ad hoc ou à utiliser des outils d'automatisation
(d'envoi de requêtes à un serveur, d'envoi d'évènements à une
IHM, ...) qui n'ont rien à voir avec du profiling.

En général, le profiler n'entre en jeu que si on n'a pas atteint
la qualité voulu. C'est carrément une perte de temps de s'en
servir avant. Et une perte de temps, c'est une augmentation du
coût pour rien.

Mais la "qualité" du code ça peut aussi être :
- ne pas utiliser à outrance l'allocation dynamique
- ne pas faire des copies inutiles de données
- bien utiliser des composants tiers gourmands en CPU
- ...

Ça peut l'être, si ces actions font qu'on ne remplit plus le
cahier de charges. (Y compris les parties implicites -- je n'ai
jamais vu écrit que la GUI ne doit pas être tellement lente
qu'elle énerve l'utilisateur, mais tout le monde sait que ce
n'est pas acceptable.)

J'ai déjà rencontré ces 3 cas et, à chaque fois, la détection
du problème a été faite avec un outil de profiling.

S'il y a un problème (constaté par les tests, par exemple),
l'utilisation du profiler est tout à fait indiqué. C-à-d quand
on sait déjà que la qualité ne suffit pas, pas pour mésurer la
qualité au départ.

--
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 wrote:

On 26 Jan 2005 03:11:31 -0800, kanze@gabi-soft.fr:

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.

Il te faut un outil pour trouver ça ? La revue du code n'a
rien dit ?

A priori, l'idée est de passer l'outil de mesure dès qu'on
reçoit le code, afin d'avoir en quelques minutes une idée de
l'étendue des dégâts. La revue de code ne vient qu'après.

Je sais, et j'aurais dû mettre un émoticon. Je ne nie pas
l'utilité des tels outils avant (et même après) la révue du
code, ne serait-ce pour signaler les composants où il faudrait
faire particulièrement attention. Mais quand même -- quand on a
des fonctions à plus de 2000 lignes, le problème saute aux yeux.

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

On 27 Jan 2005 00:28:08 -0800, kanze@gabi-soft.fr:

quand on a
des fonctions à plus de 2000 lignes

Au fait, comment fait-on des fonctions de 2000 lignes ? La seule fois
où ça m'est arrivé, c'est quand j'ai pondu un décompresseur Huffman
"en dur". Il y avait un sacré paquet de lignes, mais c'était du code
généré automatiquement...


--
;-)

Fabien LE LEZ <gramster@gramster.com> writes:

On 27 Jan 2005 00:28:08 -0800, kanze@gabi-soft.fr:

quand on a
des fonctions à plus de 2000 lignes

Au fait, comment fait-on des fonctions de 2000 lignes ? La seule
fois où ça m'est arrivé, c'est quand j'ai pondu un décompresseur
Huffman "en dur". Il y avait un sacré paquet de lignes, mais c'était
du code généré automatiquement...

On commence par une fonction de 100 lignes qu'on modifie 100 fois en
le cours de 10 ou 15 ans.

Sincerement, je n'ai jamais vu de fonctions de 2000 lignes, j'ai deja
decoupe une fonction de 1400 lignes et c'etait pas mal. Il a deja
fallu un mois pour croire comprendre comment ca marchait et en
extraire des specs. Naturellement incomplete: j'avais manque un
certain nombre de cas particuliers que j'ai decouvert lors de la
reecriture. Au final, plusieurs fonctions, un fonctionnement plus
robuste et plus homogene et quand meme quelques fonctionnalites
manquantes mais facilement ajoutees.

Dire que c'etait pas ca le plan initial, on avait eu l'erreur de faire
un step up a partir du code qu'on devait nettoye et on est tombe sur
encore pire...

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Fabien LE LEZ wrote:

On 27 Jan 2005 00:28:08 -0800, kanze@gabi-soft.fr:

quand on a
des fonctions à plus de 2000 lignes

Au fait, comment fait-on des fonctions de 2000 lignes ? La seule fois
où ça m'est arrivé, c'est quand j'ai pondu un décompresseur
Huffman

"en dur". Il y avait un sacré paquet de lignes, mais c'était du
code

généré automatiquement...

En C++, je ne sais pas.
En C, j'ai vu une fois une appli avec plusieurs dizaines de fichiers ou
chacun d'entre eux ne contenait qu'une seule fonction et les fonctions
de 1000 lignes étaient monnaie courante.
En fait, on s'y retrouvait pas trop mal car la structure était
toujours la meme : quelques bon gros mega 'switch' sur des variables
static ou passées en parametre qui définissaient un état.
La plupart des 'case' ne dépassaient pas les 50 lignes donc ca
allait... enfin pas trop longtemps quand meme...

kanze@gabi-soft.fr wrote:

Fabien LE LEZ wrote:

On 26 Jan 2005 03:11:31 -0800, kanze@gabi-soft.fr:

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.

Il te faut un outil pour trouver ça ? La revue du code n'a
rien dit ?

A priori, l'idée est de passer l'outil de mesure dès qu'on
reçoit le code, afin d'avoir en quelques minutes une idée de
l'étendue des dégâts. La revue de code ne vient qu'après.

Je sais, et j'aurais dû mettre un émoticon. Je ne nie pas
l'utilité des tels outils avant (et même après) la révue du
code, ne serait-ce pour signaler les composants où il faudrait
faire particulièrement attention. Mais quand même -- quand on a
des fonctions à plus de 2000 lignes, le problème saute aux yeux.

Je savais qu'il y avait un problème. Je voulais juste savoir à quel
point il était localisé ou étendu dans tout le projet.

--
Loïc

Fabien LE LEZ wrote:

On 27 Jan 2005 00:28:08 -0800, kanze@gabi-soft.fr:

quand on a des fonctions à plus de 2000 lignes

Au fait, comment fait-on des fonctions de 2000 lignes ? La
seule fois où ça m'est arrivé, c'est quand j'ai pondu un
décompresseur Huffman "en dur". Il y avait un sacré paquet de
lignes, mais c'était du code généré automatiquement...

Avec beaucoup de duplication de code:-). La seule fois que j'ai
vu une fonction de cette taille, elle s'appelait main, et
c'était la seule fonction dans le programme. Il a fallu six
semaines à l'auteur pour l'écrire. (En passant, il n'y avait pas
de variables locales non plus ; que des globales, avec des noms
comme i, j, etc.)

Je l'ai jeté, plutôt que de l'essayer à le mettre au point. J'ai
réimplémenté la même fonctionnalité en 12 heures et 180 lignes
(avec quelques dizaines de fonctions):-).

C'était un cas extrème, mais j'ai souvent vu des fonctions à 40
ou 50 lignes, avec cinq niveaux de contrôle de flux embriqués
(dont certains se terminaient par un return, et d'autres non).

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

Fabien LE LEZ wrote:

On 27 Jan 2005 00:28:08 -0800, kanze@gabi-soft.fr:

quand on a
des fonctions à plus de 2000 lignes

Au fait, comment fait-on des fonctions de 2000 lignes ? La
seule fois où ça m'est arrivé, c'est quand j'ai pondu un
décompresseur Huffman "en dur". Il y avait un sacré paquet
de lignes, mais c'était du code généré automatiquement...

En C++, je ne sais pas.
En C, j'ai vu une fois une appli avec plusieurs dizaines de
fichiers ou chacun d'entre eux ne contenait qu'une seule
fonction et les fonctions de 1000 lignes étaient monnaie
courante. En fait, on s'y retrouvait pas trop mal car la
structure était toujours la meme : quelques bon gros mega
'switch' sur des variables static ou passées en parametre qui
définissaient un état.

Pour chaque bonne règle, il y a des exceptions (sauf à la règle
qui dit qu'il y a toujours des exceptions). C'est un cas bien
connu qu'une fonction qui ne comporte qu'un switch avec
plusieurs centaines d'altérnatifs 1) est très longue, 2) a une
mésure de complexité cyclotomatique très élevée, et 3) est quand
même plus facile à comprendre et à maintenir que les
alternatifs. C'est un cas spécial. (La fonction la plus longue
que j'ai jamais écrit devait avoir pas loins de mille
lignes. C'était un switch avec plus de deux cents case, au coeur
d'un interpréteur de byte code.)

La plupart des 'case' ne dépassaient pas les 50 lignes donc ca
allait... enfin pas trop longtemps quand meme...

50 lignes dans un case, c'est beaucoup trop long.

En général, si une fonction dépasse une dizaine de lignes, je
commence à penser comment le découper. À moins que je suis dans
un cas d'exception. (Ça ne veut pas dire que je rejette
systèmatiquement des fonctions de douze ou de quinze lignes.
Simplement que quand j'en ai une, j'y reflechis.)

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