Discussion :

[Luc Hermitte]

a- Le SESE est utile dans certains domaines, comme les automates embarqués et sécurisés. [...]

b- Cependant, il est vrai, je ne comprends toutjours pas en quoi coder en SESE ou non est plus sécurisé. En tant que programmeur averti, je ne vois pas le problème.

c- Par contre dans l'analyse Avant/Arrière qui sert parfois pour determiner les valeurs de test de modules, une fonction non SESE devient vite pénible à analyser.

a- N'est-on pas dans un cas de C++ sans exceptions (C++ embedded ou avec options de compilations qui vont bien, voire en C simplement) ?

b- Dans un environnement pur "itératif" (sans déroutements implicites, je veux dire), c'est (était) un bon moyen d'obtenir une libération déterministe de ressources (si on ne dispose d'aucun objet automatiquement libéré en fin de portée)
Sinon, c'est plus stylistique qu'autre chose.

c- Certes, mais une simple fonction C++ (c'est important. Nous sommes ici en C++) qui fait un simple new (implicitement ou explicitement) est par défaut non SESE. Ces traitements de preuves automatiques vont alors avoir bien des difficultés. Si ils résistent aux new, ils devraient être capables de mieux résister au non SESE.

d- Au début j'étais sceptique, mais c'est vrai que quand tu as du code à lire/comprendre/débugger et que ce n'est pas le tien, ce genre de règle prend toute leur importance. C'est tout simplement plus lisible, plus facile à comprendre, [...]

e- D'un point de vue Génie Logiciel, cette règle n'est pas idiote, elle vas dans le sens de l'uniformisation du code source, ce qui procure une meilleure maintenabilité.

d- Perso, cela me ralenti plus qu'autre chose. Cela me fait chercher où ça commence, où c'est modifié et où c'est exploité (hors condition de bouclage, c'est rarement le cas sauf le jour où c'est exploité...).
Mais il est vrai que c'est plus le fait d'une fonction trop longue, que d'un SESE.

e- D'un point de vue C++, c'est ignorer le fait que les exceptions changent la donne, et qu'elles ne sont pas toujours explicites.
Et comme je le disais, je trouve que la règle : "fonction simple" est 100 fois plus importante. Hors ressources gérées à la C, c'est le seul truc qui pourrait me faire considérer le SESE.
Or je privilégie (dans la mesure du possible) la fonction simple, fonction dans laquelle le SESE n'a plus aucune impact sur l'aide à la compréhension.

f- Là où je suis d'accord, c'est qu'il faut éviter qu'une fonction contienne des structures de contrôle trop complexes, afin d'éviter le code spaguetti. Mais ça n'a rien à voir avec SESE.

f- Oui et non. Si le code est simple, le SESE n'aide en rien à mieux comprendre la fonction. Or c'est un argument fer de lance des règles de qualité pro-SESE, j'ai bien l'impression. (Plus que la gestion des ressources).

Les personnes qui n'y ont pas réfléchi et à qui j'en parle, vont plus souvent me parler de compréhension (ou maintenabilité, c'est un combat proche) de la fonction que gestion des ressources.

[moldavi]

On m'a toujours appris que dans une fonction, on élimine d'abord les cas simples, puis on traite les cas complexes.

Le cas if(i==0), est un cas simple, on sort (return), pas la peine de traîner dans la fonction.

Côté performance, j'en sais rien...

Quand j'écris une nouvelle fonction, je pense à éliminer les cas simples très rapidement. Ca me permet de programmer un peu plus rapidement parce que j'ai moins de problème lors du débugage et que je peux me concentrer plus sur l'algorithme.

Mais je dois surement utiliser les deux formes des fois. Je ne pense pas que ce soit une question existencielle de programmeur.

[Aurelien.Regat-Barrel]

Ce qui me gêne dans le SESE, c'est l'augmentation des niveaux d'ombrication dû aux blocs else supplémentaires. La règle que j'applique personnelement c'est pas plus de 3 blocs imbriqués. C'est facile de les atteindre avec le SESE.
J'ai découvert ce concept de SESE en posant une question sur le pourquoi du code suivant, si cette tournure surprenante était justifiée:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
void Test()
{
    do
    {
        /* ... */
        if ( /* erreur */ ) break;
        /* ... */
        if ( /* erreur */ ) break;
        /* ... */
        if ( /* erreur */ ) break;
        /* ... */
    } while ( 0 );
}

au lieu de quelque chose de plus "classique" :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
void Test()
{
    /* ... */
    if ( /* erreur */ ) return;
    /* ... */
    if ( /* erreur */ ) return;
    /* ... */
    if ( /* erreur */ ) return;
    /* ... */
}

Le 1° code m'avait pas mal dérouté...

[chronos]

Ce qui me gêne dans le SESE, c'est l'augmentation des niveaux d'ombrication dû aux blocs else supplémentaires.

Pareil que le monsieur, perso je suis en ce moment sur uen appi de telephone portable, le plus gros pb est le manque de memoire alors il faut tester tous les resultats d'affectation si je prends un traitement d'image
Il faut allouer dela place et a chaque nouvvelle étape verifier que l'on à la mem sachant qu'il y a au moins une diziane de passage critiques je me vois mal mettre des

Code :

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

1
2
3
 
if
  else

sur trois kilometres

Perso tant que c'est pas trop lourd SESE me parait le plus "jolie" masi aprs un certain nombre de if else au diable return en plein mileiu et hop

[Mac LAK]

En fait, je préfère utiliser un système "défensif" dans mon code : tester les préconditions (avec return systématique en cas de défaut), avec rollback des initialisations partielles précédentes si nécessaire.

A partir d'un certain stade, je suis en "terrain connu", et appliquer un SESE sur cette portion de fonction est envisageable... Mais la fonction elle-même n'est plus SESE de toutes façons !!

En plus, j'avoue que je n'ai jamais compris comment le principe SESE pouvait être compatible avec les exceptions... Or, c'est bien un forum C++, ici, non ?

J'avoue que je n'ai pas spécialement de problèmes avec les return multiples dans un code, dans le pire des cas je pose des breakpoints ou des traceurs dessus et basta ! On retrouve vite "le" return coupable...

De toutes façons, si l'on fait les choses proprement (= code d'erreur en retour de fonction, utilisation de SetLastError sur Win32, etc...), on sait systématiquement quel est le return ayant provoqué le retour... Si ce n'est pas le cas, y'a un développeur qui a codé comme un sagouin, et ça n'a rien à voir avec le fait que la fonction soit SESE ou pas.

[Tbm_rasta333]

Perso, je trouve que "if(condition)return;..." est beaucoup plus lisible, car, dans des programmes avec des dizaines de classes, structures, tests, fonctions... c'est à dire des dizaines d'accolades à la suite, on s'y perd un peu