Discussion :

[le_ptit_lutin]

Bonjour,

C'est très probablement une bête question, mais à chaque fois que j'écris une fonction, je me demande toujours s'il est mieux d'écrire les conditions de manières imbriquées ou de les mettre l'une à la suite de l'autre en invoquant un return dans le cas d'une erreur.

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
 
fn ()
{
  if (a)
  {
    if (b)
    {
      if (c)
      {
        return true;
      }
    }
  }
 
  return false;
}

ou

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
 
fn ()
{
  if (!a)
  {
    return false;  
  }
 
  if (!b)
  {
    return false;  
  }
 
  if (!c)
  {
    return false;  
  }
 
  return true;
}

Dans un soucis de clareté, je préfère la deuxième version. Mais si j'utilise des variables locales après mes conditions, seront elles déclarées et initialisées lors de l'éxécution, si une condition ne passe pas ?

Voila merci.

[jblecanard]

Tu soulèves là un débat qui va générer des pages de troll . Plus sérieusement, tout dépend du code, du nombre d'imbrications, etc. La deuxième technique est intéressante pour réduire la complexité cyclomatique quand tu as vraiment beaucoup d'imbrications.

Dans un soucis de clareté, je préfère la deuxième version. Mais si j'utilise des variables locales après mes conditions, seront elles déclarées et initialisées lors de l'éxécution, si une condition ne passe pas ?

N'aie pas peur pour tes variables : elles ne seront initialisées que si la fonction ne se termine pas avant. Le comportement que tu crains est celui de Javascript et n'a pas cours en C++.

[koala01]

Salut,

Il n'y a pas à proprement parler de "règle officielle", mais, si l'on ne s'intéresse qu'à la clarté du code, le deuxième que tu présentes est, effectivement plus lisible.

Cependant, cette manière de travailler n'est pas forcément adéquate dans toutes les circonstances: Si tu as des conditions qui ne doivent être testées que si l'une ou l'autre condition est elle-même vérifiée, par exemple.

Ce qu'il faut comprendre, c'est que l'imbrication des conditions aura un effet proche du ET logique:

Code :

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

1
2
3
4
5
6
7
if( a){
    if (b){
        if(c){
            /* correspond à if (a && b && c);    
        }
    }
}

alors que les conditions successives auront un effet plus proche du OU logique:... Voir, tout simplement de la vérification séquentielle pure et simple (en fonction de ce qui est fait dans la condition):

Code :

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

1
2
3
4
5
6
7
8
9
10
11
if(!a){
    return;
}
if(!b){
    return ;
}
if (c){
    /* correspond à peu près (s'il n'y a rien entre les différentes conditions) à
     * if (a || b || c)
     */
}

alors que le code

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
if (a){
    /* ... */
}
/* ... */
if (b){
    /* ... */
}
/* ... */
if (c){
    /* ... */
}
/* ... */

aura simplement pour effet de vérifier a, b et c dans un ordre déterminé

Et il est possible d'envisager toutes les variations qui te viendraient à l'esprit

Mais si j'utilise des variables locales après mes conditions, seront elles déclarées et initialisées lors de l'éxécution, si une condition ne passe pas ?

une variable locale n'existe qu'entre sa déclaration et l'accolade fermante de la portée dans laquelle elle est déclaré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
15
int premier; // premier est disponible partout
if (a){
    //on peut utiliser premier ici
    int sub_a; // sub_a n'existe que is on entre dans la condition
} //et est détruit ici
//debut est disponible ici
//sub_a n'est pas disponible
int second; // second n'est disponible qu'à partir d'ici
if(b){
    // on peut utiliser premier et second ici
    // ON NE PEU PAS utiliser sub_a 
    int sub_b; // sub_b est disponible à partir d'ici
} // sub_b est détruit ici
// on peut utiliser premier et second
// ON NE PEUT PAS utiliser sub_a ni sub_b ici

Mais le compilateur te le diras si tu essayes d'accéder à une variable qui n'existe pas (ou qui n'existe plus)

[EDIT] Il y a également quelques aspects "pratiques" à prendre en compte, en fonction de ce qui est testé par les conditions a, b et c.

Le résultat d'un test est toujours un booléen, qui sera toujours évalué très rapidement.

Mais l'obtention des données qui seront utilisées pour la comparaison et la comparaison elle-même, afin de fournir le booléen attendu, peuvent prendre énormément de temps.

Imagines une classe proche de

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
class MyClass{
    public:
        MyClass(std::string const & first, 
                    std::string const & second,
                    std::string const & third): first_(first), second_(second), third_(third){}
        std::string const & firstString() const{return first_;}
        std::string const & secondString() const{return second_;}
        std::string const & thirdString() const {return third_;}
        std::string complete() const{
            std::string temp(first_);
            temp.append("_")
                  .append(second_)
                  .append("_")
                  .append(third_);
           return temp;
        }
    private:
        std::string first_;
        std::string second_;
        std::string third_;
};

Tu pourrais très bien envisager de créer une variable du type de cette classe sous la forme de

Code :

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

MyClass koala("koala01", "A_nice_man","from_Belgium");

la comparaison des chaines de caractères renvoyées par les fonctins firstString, secondString et thirdString prendra, en elle-même, énormément de temps (comparé à la comparaison d'un entier) parce que, dans le pire des cas, ce sont tous les caractères de la chaine qui devront être comparés un à un au caractère équivalant dans la chaine de caractères de référence:

Code :

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

1
2
3
if(koala.first() == "koala02"){
 
}

nécessitera de comparer le 'k' avec le 'k', le 'o' avec le 'o', le premier 'a' avec le premier 'a', le 'l' avec le 'l', le second 'a' avec le second 'a', le '0' avec le '0' et le '1' avec le '2' avant d'être en mesure de dire que les deux chaines de caractères sont différentes.

Et il en ira de même pour toutes les comparaisons de chaines de caractères!

Ainsi, si tu envisage le test

Code :

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

if(koala.complete() == "koala01_A_nice_man_from_Belgium")

c'est un test qui prendra énormément de temps, parce que, pour l'exécuter, il aura fallu:

1. générer une nouvelle chaine de caractères sur base des trois chaines connues de la variable
2. comparer chaque caractères issu de la chaine de caractères ainsi obtenue avec chaque caractère de la chaine de référence

avant d'obtenir un résultat.

au final, si tes tests on simplement pour but de te permettre de sortir de la fonction, sous une forme proche de

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
if(koala.firstString() != "koala01"){
    return ;
}
if(koala.secondString() != "A_nice_man"){
    return ;
}
if(koala.thirdString() != "from_Belgium"){
    return ;
}
std::cout<< koala.complete()<<" nice to see you"<<std::endl;

cela pourra encore aller: chaque chaine de caractères n'est testée qu'une seule et unique fois.

Mais si tu base ta logique sous une forme proche de

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
/* ... */
if(koala.firstString() == "koala01"){
    /* ... */
}else{
    /* ... */
}
std::cout<<"glad to see";
if(koala.firstString() == "koala01" &&
   koala.secondString()=="A_nice_man"){
    /* ... */
} else{
    /* ... */
}
/* ... */
if(koala.firstString() == "koala01" &&
   koala.secondString()=="A_nice_man" &&
   koala.thirdString() =="from_Belgium"){
   /* ... */
} else{
   /* ... */
}

tu vas inutilement multiplier tes tests : firstString() sera testée trois fois (donc il y aura trois comparaisons de la chaine de caractères en question) et secondString() sera testée deux fois (donc, il y aura deux comparaison de la chaine).

Au final, ton programme fera ce que tu veux, mais la logique envisagée sera très clairement beaucoup moins efficace que si les tests avaient été imbriqués.

[le_ptit_lutin]

Merci pour ces éclaircissements.

En fait l'idée c'est que j'aimerais séparer les tests des variables d'entrées et le code de la fonction. Donc, je comptais sur la méthode 2 pour éliminer tout les tests préparatoires et garder une imbrication logique pour le reste. J'essaie de respecter au mieux la règle, une fonction = un taff.

Mais bon voila, ça me turlupinait un peu
Merci

[koala01]

Merci pour ces éclaircissements.

En fait l'idée c'est que j'aimerais séparer les tests des variables d'entrées et le code de la fonction. Donc, je comptais sur la méthode 2 pour éliminer tout les tests préparatoires et garder une imbrication logique pour le reste.

Dans ce cas particulier, la deuxième méthode est effectivement "préférable" car plus lisible (enfin, de mon avis personnel).

Mais uniquement parce qu'il s'agit de "vérifications préparatoires"

J'essaie de respecter au mieux la règle, une fonction = un taff.

Et tu as tout à fait raison

Note que j'ai édité mon message, pour bien te faire comprendre pourquoi il est difficile d'énoncer une règle générale