Discussion :

[fodger]

Donc à chaque fois que tu relivres une application, tu testes toutes, absolument toutes les fonctionnalités, à la main ?

Tu écrits des tests unitaires pour toutes tes fonctionnalités ? Ça revient quelque part à écrire "deux fois" l'application.

Je teste tout ce qui est lien direct avec mon dev et je fais tester par un tiers + client final si il y'a.

Avec l'inté continue en plus si le projet est important.

[George W. Bush]

Je suis d'accord avec la première moitié de la liste. Cependant, j'aurais aimé voir :

.) Considérer la robustesse d'une application comme une priorité.

.) De flexibilité de code. (MVC, N-Tier, ne pas etre oubligé de tout réécrire de A-Z, et tout d'un coup, si l'on change d'interface, de DB, de plateform.)

.) De capacité a produire des solutions avec une grande durée de vie.

.) De globalisation. (combien de fois j'ai vue des solutions pour grande entreprise, avec du hard-codage, des centaines de fichiers de parametres pelle-mèles, des shares qui pointent n'importe ou, rendant la solution très difficile a administrer)

.) De gestion des erreurs. (trop souvent minimisé, et implenté en fin de projet, plutot qu'en début)

Au plaisir,
Voila.

[popo]

et tu le sort comment ton indicateur qualité (ou alors tu le sort pas du tout, quand même pas !) ?

Les outils d'intégration continue sont là pour ça (Jenkins, sonar...).

Et bien justement, sonar, pour ne citer que lui mesure une partie de l'indicateur qualité avec le code coverage.

Mon nouveau test sert à garantir que le bug est bien corrigé et les tests déjà existants m'assurent que je n'ai rien cassé ailleurs.

Il ne garantit en rien que tu ais écrit un code de qualité, intelligent et que tu ais réellement couvert toutes les situations.
Le test par un tiers avec de l'intégration continue restent très efficaces.

En effet, il ne garantissent en rien la qualité du code. Mais j'ai également évoqué SRP et le nommage entres autres, qui même s'il ne font pas tout permettent néanmoins d'améliorer les choses.
Quand a couvrir toute les situations, c'est justement le rôle du test unitaire... quand un cas n'est pas couvert, on écrit un nouveau test, on corrige et se base sur les tests existant pour la non régression. Après si pour une même fonctionnalité, il y a trop souvent un nouveau cas de bug découvert, c'est un bon indicateur pour savoir que soit l'analyse ne correspond pas au besoin (bref qu'on a pas compris ce qu voulais le client), soit qu'elle a été baclée. Dans les deux cas il faudra revoir le client. Et en passant, le test effectué par un tiers non plus ne garantit ni la qualité du code ni la couverture de tous les cas. Si un cas a été oublié dans l'analyse, ce cas sera oublié aussi bien dans les tests unitaires, que dans les tests manuels ou par les robots de tests.

Pyramidev, il y a de nombreuse manières d'éviter un commentaire.
Pour ton exempler avec "FaireUnTrucA, FaireUnTrucB". Il suffit de déclarer ces méthodes en dessous de uneFonction, il aura tout directement sous les yeux.
Pour le cas des chaines de format je suis d'accord qu'un commentaire peut être utile. Quoique, certain diraient qu'on peux également renvoyer une exception et expliquer le format à l'intérieur.
Pour le findIndex, là je ne suis pas d'accord. En règle général, il existe déjà de telles méthodes dans le framework ou dans les librairies et les développeurs savent que ce genre de méthodes est sensée renvoyer l'indice de l'élément à partir de 0, ou -1 si non trouvé.
Pour le findElement, là encore, je ne suis pas d'accord. Ton Objet est dépendant d'un autre qui a potentiellement sa vie propre et tu n'ai pas en mesure de garantir sa longévité. Pour moi cette classe ne respecte ni principe d'encapsulation, ni le SRP. Il te faut une classe dédiée pour la gestion des configurations, une classe qui contiendra sa propre liste et dont la méthode findElement renverra une copie de l'item.

[fodger]

Et bien justement, sonar, pour ne citer que lui mesure une partie de l'indicateur qualité avec le code coverage.


En effet, il ne garantissent en rien la qualité du code. Mais j'ai également évoqué SRP et le nommage entres autres, qui même s'il ne font pas tout permettent néanmoins d'améliorer les choses.
Quand a couvrir toute les situations, c'est justement le rôle du test unitaire... quand un cas n'est pas couvert, on écrit un nouveau test, on corrige et se base sur les tests existant pour la non régression. Après si pour une même fonctionnalité, il y a trop souvent un nouveau cas de bug découvert, c'est un bon indicateur pour savoir que soit l'analyse ne correspond pas au besoin (bref qu'on a pas compris ce qu voulais le client), soit qu'elle a été baclée. Dans les deux cas il faudra revoir le client. Et en passant, le test effectué par un tiers non plus ne garantit ni la qualité du code ni la couverture de tous les cas. Si un cas a été oublié dans l'analyse, ce cas sera oublié aussi bien dans les tests unitaires, que dans les tests manuels ou par les robots de tests.

Pyramidev, il y a de nombreuse manières d'éviter un commentaire.
Pour ton exempler avec "FaireUnTrucA, FaireUnTrucB". Il suffit de déclarer ces méthodes en dessous de uneFonction, il aura tout directement sous les yeux.
Pour le cas des chaines de format je suis d'accord qu'un commentaire peut être utile. Quoique, certain diraient qu'on peux également renvoyer une exception et expliquer le format à l'intérieur.
Pour le findIndex, là je ne suis pas d'accord. En règle général, il existe déjà de telles méthodes dans le framework ou dans les librairies et les développeurs savent que ce genre de méthodes est sensée renvoyer l'indice de l'élément à partir de 0, ou -1 si non trouvé.
Pour le findElement, là encore, je ne suis pas d'accord. Ton Objet est dépendant d'un autre qui a potentiellement sa vie propre et tu n'ai pas en mesure de garantir sa longévité. Pour moi cette classe ne respecte ni principe d'encapsulation, ni le SRP. Il te faut une classe dédiée pour la gestion des configurations, une classe qui contiendra sa propre liste et dont la méthode findElement renverra une copie de l'item.

C'est tout l'intérêt de faire appel à un tiers - n'ayant pas de lien direct avec ton dev - pour tester. Le défaut récurrent chez le dev étant lors de ses tests de ne pas se mettre dans la peau d'un utilisateur "lambda".

Les tests unitaires peuvent être intéressants pour garantir l'intégrité de données, mais le test unitaire technique à tout va non, non et encore non.
C'est très long, fastidieux, c'est lourd.

Plutôt que de sauter et de se rassurer avec le tout test unitaire technique, on a plus intérêt à se concentrer sur la maitrise réelle du langage tout en appliquant les bonnes pratiques. L'impact est bien plus important sur la qualité intrinsèque et plus globale.

[ddoumeche]

Tu écrits des tests unitaires pour toutes tes fonctionnalités ? Ça revient quelque part à écrire "deux fois" l'application.

Je teste tout ce qui est lien direct avec mon dev et je fais tester par un tiers + client final si il y'a.

Avec l'inté continue en plus si le projet est important.

Pour le maximum de fonctionnalités, en effet même si les tests unitaires sont relativement simples comparés à du code métier.

Mais les test unitaires :

• ne sont pas plus long à écrire que de déboguer son code a la main
• m'obligent a conserver une architecture simple et testable
• me font détecter rapidement les régressions
• surtout s'ils sont fait automatiquement
• permettent d'éviter qu'un nouveau venu ne casse tout en voulant bien faire

Mais cela n'empêche pas les tests fonctionnels à la fin de la livraison.

Bref cela oblige a un changement d'habitudes.

Et bien justement, sonar, pour ne citer que lui mesure une partie de l'indicateur qualité avec le code coverage.

Je n'ai pas vu encore l’intérêt de tel outils mis à part pour les équipes comprenant des programmeurs débutants, pour qui une relecture de code devrait s'imposer.
Sont-ils vraiment adaptés à tous les projets ?

[Pyramidev]

Il te faut une classe dédiée pour la gestion des configurations

Pourrais-tu développer ce point ?

Je vais prendre le scénario suivant :
Une certaine configuration est lue en début de programme depuis un fichier (s'il n'existe pas, le fichier est créé).
En cours d'exécution du programme, la configuration peut changer suite à des actions de l'utilisateur.
Lors d'une sauvegarde, la configuration est sauvegardée dans le fichier.

Pour implémenter cela en C++, j'ai pensé à la solution suivante :
Vers le début du programme, je construis un objet de type Config qui représente le contenu du fichier.
Ensuite, en cours d'exécution du programme, dans les objets que je construis dont le comportement dépend de la config, je sauvegarde dans chaque objet un handler qui permet d'accéder à l'objet config en lecture, par exemple un const Config& ou un std::reference_wrapper<const Config>. D'où mon exemple :

Code :

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

1
2
3
4
/*!
 * \param config Cet objet doit exister tant que Foo existe.
 */
Foo(const Config& config);

Quand la config sera modifiée, la prochaine fois que Foo lira la config, il lira la config à jour.
En fin de programme, je laisse se détruire tous les objets encore vivants qui lisaient la config.
Ensuite, je laisse cet objet de type Config se détruire.
(En C++, dans pas mal de cas, les objets sont détruits dans l'ordre inverse de leur création.)

Remarques :

• Pour respecter le principe de la ségrégation d'interface (ISP), Config pourrait hériter de différentes petites interfaces.
  

  Code :

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

  1
  2
  3
  4
  /*!
   * \param config Cet objet doit exister tant que Bar existe.
   */
  Bar(const InterfaceImplementeeParConfig& config);

  Je n'ai pas trop insisté dessus pour que l'exemple reste simple. De toute façon, ça ne change pas la gestion de la mémoire.
• Dans chaque objet, j'aurais pu mettre un std::shared_ptr<const Config> qui gère la mémoire de l'objet via un comptage de références. Le dernier qui n'utilise plus la config se charge alors de la détruire. En plus, cela évite de documenter à propos de la gestion de la mémoire. Mais cette solution me semble inappropriée dans cet exemple car je sais déjà quand l'objet de type Config devra être détruit. Ici, le comptage de références serait un surcoût inutile.

[popo]

C'est tout l'intérêt de faire appel à un tiers - n'ayant pas de lien direct avec ton dev - pour tester. Le défaut récurrent chez le dev étant lors de ses tests de ne pas se mettre dans la peau d'un utilisateur "lambda".

Je suis d'accord pour dire qu'un développeur n'arrive pas souvent à se mettre dans la peau d'un utilisateur lambda.
Il n'empêche que quelque soit le tiers qui teste, celui-ci va se baser sur l'analyse pour savoir si un cas qu'il rencontre est correct ou non.
Si ce tiers tombe sur un cas non prévu, il va le dire au dire au développeur (et si je suis ce développeur, je fais d'abord écrire une méthode de test avant de corriger).
Relis bien, je n'ai écrit nulle part qu'un test fonctionnel est inutile, c'est toi qui a interprété.
Evidemment que les tests fonctionnels sont important puisque, justement, ils permettent de lever les loups que le développeur n'a pas vu.

Les tests unitaires peuvent être intéressants pour garantir l'intégrité de données, mais le test unitaire technique à tout va non, non et encore non.
C'est très long, fastidieux, c'est lourd.

Si faire un test unitaire est fastidieux et/ou lourd, cela signifie en général que le code de production l'est également.
Comme le dis si bien ddoumeche :

Mais les test unitaires :
•ne sont pas plus long à écrire que de déboguer son code a la main
•m'obligent a conserver une architecture simple et testable
•me font détecter rapidement les régressions
•surtout s'ils sont fait automatiquement
•permettent d'éviter qu'un nouveau venu ne casse tout en voulant bien faire

Plutôt que de sauter et de se rassurer avec le tout test unitaire technique, on a plus intérêt à se concentrer sur la maitrise réelle du langage tout en appliquant les bonnes pratiques. L'impact est bien plus important sur la qualité intrinsèque et plus globale.

ça fait deux fois que tu me sors l'argument du "tout tester unitairement ne suffit pas".
Et donc, ça fait deux fois que je constate que tu ne prends pas le temps tout lire. Je ne prendrai donc pas la peine de tout réécrire.

Il te faut une classe dédiée pour la gestion des configurations

Pourrais-tu développer ce point ?

Je n'ai jamais fait de C++ donc je ne sais pas si cela représente une difficulté ou non.
En tout cas, je pensais à simple singleton encapsulant l'objet Config.

[olibiobus]

Un code est de bonne qualité si et seulement s'il est Bien commenté !
Avant même d'écrire le code, je le commente; cela a trois avantages:
1) éviter des oublis, préparer le futur codage
2) permettre la mise à jour plus facile du code y compris par un autre développeur
3) entrer rapidement et de façon globale dans un code, ce qui facilite les optimisations si nécessaire

[Pyramidev]

En tout cas, je pensais à simple singleton encapsulant l'objet Config.

En effet, c'est une autre solution.
Je ne suis pas un grand fan des singletons, mais c'est vrai que ça marche.

Pour ton exempler avec "FaireUnTrucA, FaireUnTrucB". Il suffit de déclarer ces méthodes en dessous de uneFonction, il aura tout directement sous les yeux.

Je modifie légèrement l'exemple. Je vais prendre le cas particulier de Java :

Code :

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
public void uneFonction()
{
    Foo foo1 = null;
    Foo foo2 = faireUnTrucA(foo1);
    Bar bar1 = null;
    Bar bar2 = faireUnTrucB(bar1);
    faireUnTrucC(foo1, foo2, bar1, bar2);
}
private final Foo faireUnTrucA(Foo foo1)
{
   foo1 = du code
   du code
   du code
   return du code
}
private final Bar faireUnTrucB(Bar bar1)
{
   bar1 = du code
   du code
   return du code
}
private final void faireUnTrucC(Foo foo1, Foo foo2, Bar bar1, Bar bar2)
{
   du code
   du code
   du code
   du code
   du code
}

Je pense que le même bout de code sera plus lisible et plus commode à maintenir sous cette forme :

Code :

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
public void uneFonction()
{
    // faire un truc A
   Foo foo1 = du code
   du code
   du code
   Foo foo2 = du code

    // faire un truc B
   Bar bar1 = du code
   du code
   Bar bar2 = du code

    // faire un truc C
   du code
   du code
   du code
   du code
   du code
}

Les autres inconvénients qui me viennent à l'esprit sur le code avec les fonctions faireUnTrucX ne sont pas vrais pour tous les langages.

Par exemple, en C++, le temps de recompilation risque d'être en moyenne plus long dans la solution avec les fonctions faireUnTrucX membres de la classe.
En C++, souvent, on déclare les fonctions dans un fichier ".h" et on les implémente dans un fichier ".cpp". Alors, il y a de fortes chances que les fonctions membres faireUnTrucX soient déclarées dans le ".h".
Quand on ne modifie qu'un fichier ".cpp", pour recompiler le projet, on a juste besoin de recompiler ce ".cpp". Par contre, quand on modifie un ".h", il faut recompiler tous les ".cpp" qui incluent, directement ou indirectement ce ".h", ce qui est plus long.
Dans la solution avec les fonctions membres faireUnTrucX, si on modifie le nom ou la liste des paramètres d'une des fonctions membres faireUnTrucX, il faut modifier sa déclaration dans le ".h", donc modifier le ".h".
Dans l'autre solution, par contre, on ne fait que changer le code de uneFonction dans le ".cpp".

[popo]

Pyramidev.
Encore une fois, je ne connais pas le C++ alors je me trompe peut être.
Est-ce qu'on est obligé de déclarer chacune des fonctions dans le fichier .h ?
L'idée est de déclarer uniquement les méthodes publiques dans le fichier .h et de découper dans le fichier .cpp
Comme une interface (c'est du Delphi cette fois) :

Code Delphi :

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

1
2
3
4
5
6
7
8
9
10
11
12
IMyInterface = interface
['{D653EBB8-78FD-4F69-A771-B659449A4872}']
  procedure UneMethode;
end;
 
TConfigurationSerializer(TInterfacedObject, IMyInterface)
private
  procedure FaireUnTrucA;
  procedure FaireUnTrucB; 
public
  procedure UneMethode;
end;

Un code est de bonne qualité si et seulement s'il est Bien commenté !
Avant même d'écrire le code, je le commente; cela a trois avantages:
1) éviter des oublis, préparer le futur codage
2) permettre la mise à jour plus facile du code y compris par un autre développeur
3) entrer rapidement et de façon globale dans un code, ce qui facilite les optimisations si nécessaire

C'est tout le contraire selon moi, un code de bonne qualité est un code où tout est limpide sans avoir besoin de commentaires
1) Pour préparer le futur codage on a jamais fait mieux que le papier et le crayon (et les commentaire n'empêchent pas les oublis). Le mieux est de le mettre au propre pour les futurs collègues qui reprendront le code (y compris nous même).
2) La plupart des développeurs effectuant de la maintenance ou une correction vont modifier le code, voire le déplacer, et en grande majorité (en tout cas c'est ce que j'ai pu constater) le commentaire restera tel quel. On aboutit à un commentaire complètement hors de propos à l'endroit où il est resté et ça ne facilite pas vraiment les choses.
3) Se reporter à mon commentaire 1. Car si ce document existe et qu'il est facile d'accès, le prochain développeur n'aura aucun mal à s'y retrouver.

[DonQuiche]

Encore une fois, je ne connais pas le C++ alors je me trompe peut être.
Est-ce qu'on est obligé de déclarer chacune des fonctions dans le fichier .h ?
L'idée est de déclarer uniquement les méthodes publiques dans le fichier .h et de découper dans le fichier .cpp

Oui et non. Toute fonction doit avoir été déclarée avant d'être appelée.

Tu peux à la rigueur organiser l'ordre des fonctions dans ton cpp pour éviter d'avoir une déclaration redondante (en imposant un ordre de lecture du bas niveau vers le haut niveau), ou tu peux placer la déclaration en haut du cpp plutôt que dans le header. Mais tu es quand même en général obligé de te farcir des déclarations distinctes à cause de ce modèle de compilation anachronique, datant d'une époque où l'AST ne pouvait pas tenir en mémoire.

Coder en C++ c'est comme se faire un gang-bang dans une maison de retraite : ça sent la naphtaline et tu risques de contracter une saleté.

[foetus]

Pour préciser ce que dit DonQuiche , on peut effectivement mettre des "forward declarations" en premier/ haut dans son fichier source .cpp.
Et ensuite, coder leurs définitions où on veut dans ce fichier.

Et une autre méthode qui fonctionne avec les fonctions/ procédures mais pas avec une classe/ méthodes.
On peut faire 2 entêtes .h: une XXX.h et une XXX_private.h

Dans l'entête XXX.h on place tout ce qui est public.
Dans l'entête XXX_private.h, on fait un #include "XXX.h" et on y ajoute tout ce qui est privé

Et dans le source XXX.c on fait un #include "XXX_private.h"

[Pyramidev]

Dans un programme, les commentaires qui me semblent les plus importants sont ceux qui décrivent, pour chaque classe, en quelques lignes, quel est le rôle de cette classe dans le programme. Quand un nouveau développeur débarque sur le projet, ça lui permet d'être moins perdu les premiers temps.

Est-ce qu'on est obligé de déclarer chacune des fonctions dans le fichier .h ?
L'idée est de déclarer uniquement les méthodes publiques dans le fichier .h et de découper dans le fichier .cpp

Dans ce cas, une solution est d'utiliser la méthode dite du pointeur opaque / de l'idiome pimpl.
En gros, on a une classe FooImpl qu'on déclare et qu'on définit entièrement dans Foo.cpp.
Dans Foo.h, on définit une autre classe, Foo, qui ne contient qu'un pointeur vers FooImpl et des méthodes publiques. Dans Foo.cpp, on définit ces méthodes de Foo.
Alors, chaque fois qu'on touche à un détail d'implémentation, on n'est pas obligé de toucher à Foo.h. Pour le temps de recompilation, c'est super.
Mais le code est un peu plus lourd à écrire et il y a un petit coût supplémentaire à l'exécution car on a ajouté une indirection entre les méthodes de Foo et les données. Donc la méthode dite du pointeur opaque n'est pas systématiquement utilisée en C++.

[CedricMocquillon]

foetus,
On n'a pas interprété utiliser les lignes de commandes plutôt que les interfaces graphiques (GUI) de la même manière.
Je l'avais compris comme, par exemple, utiliser SVN en ligne de commande au lieu d'utiliser un logiciel comme Tortoise SVN.
Par contre, pour un outil que l'on code soi-même, j'entends qu'on n'a pas toujours le temps de coder une interface graphique, ce qui, de toute façon, n'est pas incompatible avec le fait de pouvoir utiliser l'outil directement en ligne de commande.


Ce n'est pas une question de lisibilité.
Dans mon exemple avec if(entier1 + entier2 < entier3), quand on arrive à cette ligne, on peut connaître directement la valeur de ces trois entiers, par exemple en passant la souris dessus (avec un bon débogueur).
Par contre, dans mon autre exemple avec if(uneFonctionQuiRetourneUnEntier(param1) + uneFonctionQuiRetourneUnEntier(param2) < uneFonctionQuiRetourneUnEntier(param3)), pour connaître les valeurs des entiers retournés, il faut entrer dans la fonction, ce qui est moins pratique.

Je voulais rebondir là dessus, je sais pas pour les autres debugers/langages mais en C++ avec VisualStudio (il me semble valable pour C# et VB.Net) tu as l'information des valeurs renvoyées par chacune des méthodes. Donc personnellement je suis moins catégorique: j'aime pas introduire des variables locales qui ne "servent à rien" mais si l'expression commence à être complexe c'est que de toute manière le code sera difficile à lire; dans ce cas j'introduis des variables intermédiaires plus dans l'optique d'améliorer la compréhension du code.

[Pyramidev]

Je voulais rebondir là dessus, je sais pas pour les autres debugers/langages mais en C++ avec VisualStudio (il me semble valable pour C# et VB.Net) tu as l'information des valeurs renvoyées par chacune des méthodes.

Je viens de tester avec Visual C++ 2010 Express avec la ligne de code suivante :

Code :

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

if(carre(3) + carre(4) == carre(5))

J'ai fais trois fois "Pas à pas détaillé"-"Pas à pas sortant".
Après chaque "Pas à pas sortant", je pouvais voir dans l'IDE la valeur retournée par la fonction carre de laquelle je suis sorti. Mais cette valeur n'était plus visible à partir du "Pas à pas détaillé" suivant.
Par contre, quand je stocke des résultats dans des variables locales "inutiles", je peux les visualiser tant qu'elles n'ont pas été dépilées.

[CedricMocquillon]

Effectivement, je ne sais pas depuis combien de temps c'est disponible dans les versions de visual (2010 c'est vieux quand même!)
Sur la version 2015 (disponible en version express ou community), le code suivant:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
int foo() {
	return 10;
}

int bar() {
	return 20;
}

int main() {
	auto result = foo() + bar();
}

avec break point sur la ligne "auto result" puis F10 me donne bien toutes les infos:

[zulad]

Je crois que le café n'est pas si bon que ça pour un développeur quand il prend une pause. Par contre, je pense que dans ce métier on se doit de faire plus de pause que dans d'autres...

[micka132]

Je pense que le même bout de code sera plus lisible et plus commode à maintenir sous cette forme :

Pour une petite fonction ca peut passer, mais après c'est juste immonde!
Je me suis déjà retrouver à devoir modifier une fonction de plus de 3500 lignes...
Ben franchement j'aurais mis beaucoup moins de temps si c'était éclaté en 10 méthodes elles même divisé en 10 méthodes.

[Pyramidev]

Je me suis déjà retrouver à devoir modifier une fonction de plus de 3500 lignes...
Ben franchement j'aurais mis beaucoup moins de temps si c'était éclaté en 10 méthodes elles même divisé en 10 méthodes.

Entièrement d'accord. Moi non plus, je n'aime pas les fonctions qui font 2 km.

A part ça, parmi les cas où je suis en faveur des commentaires, j'avais oublié de mentionner les cas suivants :

• De manière générale, expliquer un choix fait dans le code.
  Par exemple, si on fait tel truc bizarre dans le code, c'est pour contourner tel bogue de tel IDE.
  Autre exemple : Si on a implémenté telle classe de telle manière qui est moins flexible que telle autre manière, c'est pour des raisons de performance de tel programme.
• Pour une classe ou une fonction qui n'est pas la plus adaptée (flexibilité, performance…) dans un certain contexte, conseiller d'utiliser telle autre classe ou fonction dans ce contexte.
  Par exemple, une fois, dans une classe abstraite, j'avais une fonction foo qui faisait une certaine opération, une fonction bar qui faisait une autre opération et une fonction foobar qui faisait ces deux opérations à la fois. J'ai écrit en commentaire pour signaler à l'utilisateur de la classe qu'il était préférable d'appeler directement foobar plutôt que, successivement, foo et bar, car c'était plus performant avec certaines classes dérivées.
• Pour une classe commune à plusieurs applications, écrire qu'il ne faut pas ajouter de variable membre à cette classe, car elle est très utilisée dans tel programme qui a été optimisé pour consommer peu de mémoire.
• Pour une classe commune à plusieurs applications qui ne compilent pas forcément avec le même environnement, écrire qu'elle doit pouvoir compiler sur tel programme qui n'a pas accès à tel environnement, qui compile avec tel IDE qui ne supporte pas certaines fonctionnalités récentes du langages ou qui a tel bogue à contourner…

PS : Dans le pseudocode Java que j'avais écrit quelques messages plus haut, je me suis gouré : j'avais oublié que les poignées étaient passées par valeur (et pas par référence) en paramètre de fonction.

[el_slapper]

Entièrement d'accord. Moi non plus, je n'aime pas les fonctions qui font 2 km.
(.../...)

ça dépend. Ce que j'ai pas mal pratiqué en bancaire, ce sont des traitements par nature très linéaires, ou tu fais des choses au kilomètre, que tu ne fais nulle part ailleurs, et qui sont juste en séquence. Il y a zéro valeur ajoutée à découper tout ça en rondelles.

Mais c'est un cas particulier. Le cas général, avec plein de SI(pleindelignes)SINON(pleindautreslignes), lui nécessite un découpage fréquent en petits morceaux.