rendements précoces vs imbriquées positif si les déclarations

Voici quelques exemple de code hypothétique:rendements précoces vs imbriquées positif si les déclarations

if (e.KeyCode == Keys.Enter) 
{ 
    if (this.CurrentElement == null) { 
     return false;} 

    if (this.CurrentElement == this.MasterElement) { 
     return false;} 

    if (!Validator.Exist (this.CurrentElement)) { 
     return false;} 

    if (!Identifier.IsPictureElement (this.CurrentElement)) { 
     return false;} 

    this.FlattenObjects(this.CurrentElement); 
}

if (e.KeyCode == Keys.Enter) 
{ 
    if (this.CurrentElement != null) { 

     if (this.CurrentElement != this.MasterElement) { 

      if (Validator.Exist (this.CurrentElement)) { 

       if (Identifier.IsPictureElement (this.CurrentElement)) { 

        this.FlattenObjects(this.CurrentElement);}}}}}} 

}

Lequel pensez-vous vaut mieux en termes de lisibilité, d'entretien, etc.?

Le deuxième exemple peut également être formaté différemment via l'utilisation différente des parenthèses.

Source

2010-12-06 Joan Venge

+18

C'est l'un des pires styles de renfort que j'ai jamais vu. – SLaks

Hehe, j'ai effectivement vu un vrai code comme ça. Mais désolé je me suis précipité pour le taper comme ça, ça irait mieux avec un bracketing correct. –

http://stackoverflow.com/questions/237719/what-is-the-most-frustrating-programming-style-youve-encountered/930831#930831 – SLaks

Les retours anticipés sont beaucoup plus lisibles.

Chaque fois que vous obtenez plus de quatre ou cinq niveaux d'imbrication dans une méthode, il est temps de refactoriser cette méthode.

Un if simple avec une clause || peut parfois être plus lisible:

if (this.CurrentElement == null 
|| this.CurrentElement == this.MasterElement 
|| !Validator.Exist(this.CurrentElement) 
|| !Identifier.IsPictureElement(this.CurrentElement)) 
    return false;

Source

2010-12-06 18:49:07 SLaks

Merci, c'est un style intéressant. Mais comment le formater avec 4-5 niveaux d'imbrication, ce qui signifie 4-5 contrôles, non? Donc, la méthode ci-dessus, pourriez-vous la refactoriser, en la décomposant en différentes méthodes? –

@Joan: Cela dépend complètement du code. Cependant, vous voudrez peut-être faire une méthode séparée qui effectue toutes les vérifications et retourne 'true' ou' false'. – SLaks

Merci, j'ai compris. C'est juste que parfois, vous obtenez ces cas uniques très indépendants qui nécessitent beaucoup de contrôles, mais ne peuvent pas être facilement combinés en moins de méthodes, mais je vois ce que vous voulez dire. –

Je pense que je l'écrire comme:

if (this.CurrentElement == null OR this.CurrentElement == this.MasterElement OR ...) return false;

Source

2010-12-06 18:49:58 PeeHaa

Moi aussi, mais sur plusieurs lignes et avec la syntaxe correcte. – SLaks

Ony avec les nouvelles lignes? –

Merci, mais quand je le fais, les lignes deviennent parfois très longues, disons avec 6 chèques. –

Le premier exemple est mieux dans tous les sens. C'est plus simple et plus facile à lire. Certaines personnes disent que chaque fonction devrait avoir un seul point de retour; Cet exemple montre clairement pourquoi ces gens ont tort.

PS Personnellement, je supprimerait toutes ces accolades superflus:

if (this.CurrentElement == null) return false;

etc. Cela rend encore plus simple, et encore plus facile à lire.

Source

2010-12-06 18:52:18 TonyK

Je pense que la plupart des gens ont eu la mauvaise idée d'une seule entrée/sortie unique - voir [ce post] (http://softwareengineering.stackexchange.com/a/118793) – andreee

Je dirais que le premier est meilleur pour la lisibilité et la maintenance. Cependant, je l'écrirais probablement quelque chose comme ça.

if (e.KeyCode == Keys.Enter) { 
    if(this.CurrentElement == null || 
     this.CurrentElement == this.MasterElement || 
     !validator.exists(this.CurrentElement) || 
     !identifier.isPictureElement(this.CurrentElement)) 
    { 
     return false; 
    { 
    else 
    { 
     this.flattenObjects(this.CurrentElement); 
    } 
}

Source

2010-12-06 18:54:19 OrangeDog

Merci, mais n'est pas des classes, des méthodes supposées être PascalCase? –

Je supposais Java, et ce validateur/identificateur étaient des objets. – OrangeDog

Ok, je vois ce que tu veux dire. Oui, je pense toujours au mode C#/.NET mais cette technique est toujours valable bien sûr. –

Étant donné que dans le second exemple « false » est le retour pour tous les chemins, mais il est implicite plutôt que déclarée pourquoi ne pas simplement faire toutes les déclarations implicitement faux et tester simplement une condition qui est unique?

Ceci pourrait enfreindre les règles de style de quelqu'un mais est logiquement le plus succinct.

if(e.KeyCode == Keys.Enter 
&& this.CurrentElement != null 
&& this.CurrentElement != this.MasterElement 
&& Validator.Exist (this.CurrentElement)      
&& Identifier.IsPictureElement (this.CurrentElement)) 
    this.FlattenObjects(this.CurrentElement);

Source

2016-11-21 17:40:57

rendements précoces vs imbriquées positif si les déclarations

Répondre

Questions connexes