2010-08-24 9 views
2

Pourrais-je écrire la logique suivante d'une manière plus simple et plus facile à lire? Le ci-dessous est ce que je dois, mais il est très salissant:Cette logique if-else-else peut-elle être réécrite en quelque chose de plus propre?

if (IsChanged == true) 
{ 
    return; 
} 

else if (Status == "" && IsChanged == false) // Executed when the close (x) button is pressed, as the Status string is not yet set to a real value... 
{ 
    CancelClose(); 
} 

else if (IsChanged == false && Status == "saving") // saving logic falls to here... 
{ 
    // IsChanged = false; 
} 

Merci

+12

'== (true | false)' est du diable. Du diable, je dis! – delnan

+0

Oui, allez avec '! IsChanged' sur' IsChanged == False' – Skilldrick

+1

Utilisez une chaîne.Videz pas "" pour éviter la création d'objets inutiles –

Répondre

12

C'est un peu plus propre:

if (IsChanged) 
{ 

} 
else if (Status == "saving") 
{ 

} 
else if (Status == "") 
{ 

} 
else 
{ 

} 

Je vous recommande d'utiliser un enum pour représenter l'état. Cela permettra à votre code d'être fortement typé.

public enum Status 
{ 
    Closing, 
    Saving, 
    Changed, 
} 

Ensuite, vous pouvez utiliser une instruction switch agréable de décider des mesures à prendre.

switch (_status) 
{ 
    case Status.Saving: 
     break; 
    case Status.Closing: 
     break; 
    case Status.Changed: 
     break; 
    default: 
     break; 
} 
+0

Ne vérifie pas Status == "" dans l'autre cas – recursive

+2

+1 pour utiliser enum. – Charles

20
if (isChanged) return; 

switch (Status) { 
    case "": 
     CancelClose(); 
     break; 
    case "saving": 
     // IsChanged = false; 
     break; 
} 

Ceci est à peu près aussi propre qu'il obtient. Notez que parce que vous renvoyez si isChanged est vrai, vous pouvez toujours supposer que isChanged est false.

+0

Je pense que c'est la solution la plus efficace, en fixant les deux côtés. – Jookia

+0

"if (isChanged == true)" peut être réécrit comme "if (isChanged)". – TrueWill

+0

pourrait sauver la partie '== true' –

1

oui:

if (IsChanged) return; 
    if (String.IsNullOrEmpty(Status)) CancelClose(); 
+1

C'est incomplet, il vous manque un point pour la logique d'enregistrement - dans laquelle vous ne voulez pas tomber si vous appelez CancelClose –

+0

Ce que j'ai ci-dessus équivaut à échantillon présenté, comme rien ne se passe dans le dernier bloc de toute façon (sauf si la propriété status a des effets secondaires en plus de renvoyer une valeur de chaîne, ce qui serait très très mauvais ...) –

4
if(IsChanged) 
    return; 

if(Status == "saving") 
{ 
    // save  
} 
else if(string.IsNullOrEmpty(Status)) 
{ 
    CancelClose();  
} 
+0

Absolument aucun point vérifiant si 'isChanged' est faux quand il aurait retourné si c'était vrai – Skilldrick

+0

Ne vérifie pas Status == "" dans l'autre cas – recursive

+2

Cela échouerait si plus d'options pour le statut sont disponibles –

0

Il peut être simplifed pour

if (IsChanged) 
    { 
     return; 
    } 

    else if (Status == "") // Executed when the close (x) button is pressed, as the Status string is not yet set to a real value... 
    { 
     CancelClose(); 
    } 

    else if (Status == "saving") // saving logic falls to here... 
    { 
     //  IsChanged = false; 
    } 

Vous n'avez pas besoin == vrai dans le premier chèque, car il est déjà vrai ou faux. vous n'avez pas besoin de vérifier false dans les autres choix car si ce n'est pas vrai, il doit être faux.

2

Puisque vous revenez si IsChanged == true, vous n'en avez pas besoin dans les autres ifs.

if (IsChanged == true) 
     return; 

    switch (Status) 
    { 
     case "": 
     CancelClose(); 
     break; 
     case "saving": 
     break; 
    } 
+1

J'ai tendance à éviter l'instruction 'switch' pour un petit nombre de chaînes – ChaosPandion

+0

Je pense que l'avantage s de l'instruction switch dans ce cas est cela. Vous pouvez facilement voir comment le flux dépendra du statut (et pas d'autres variables), et on peut facilement imaginer ajouter plus de cas en fonction des nouvelles valeurs de Status. – HaskellElephant

0
if (IsChanged) return; 

if (Status == "saving") 
{ 
    //IsChanged = false; 
} 
else if (Status = "") 
{ 
    CancelClose(); 
} 

il faut éviter de commencer vos noms de variables avec majuscules.

+0

Vous pouvez tout sortir du grand bloc else. – recursive

+0

Peut-être 'IsChanged' et 'Status' sont des propriétés? –

+0

Ce sont des noms de propriété, et les noms de propriétés commencent généralement par une lettre majuscule. L'alternative serait quelque chose comme un _isChanged privé. – Thorsten79

1
  • couper le premier sinon si juste. Si IsChanged est vrai, le "else" ne sera jamais atteint.
  • supprime le IsChanged == false de vos autres ifs car ils sont toujours vrais.
  • Pensez à enums au lieu de chaînes pour votre statut.

Je recommande:

if (IsChanged) 
{ 
     return; 
} 

if (CurrentStatus == Status.None) 
{ 
    CancelClose(); 
    return; 
} 

if (CurrentStatus == Status.Saving) 
{ 
    //  IsChanged = false; 
} 
1
if(!IsChanged) { 
     if (Status == "saving") // saving logic falls to here... 
     { 
      //  IsChanged = false; 
     } 
     else if (Status == "") // Executed when the close (x) button is pressed, as the Status string is not yet set to a real value... 
     { 
      CancelClose(); 
     } 
    } else { 
     return; 
    } 
0
if (IsChanged) 
    return; 

if (String.IsNullOrEmpty(Status)) // better use this unless you would like a 
    CancelClose();     // nullPointerException 

else if (Status.equals("Saving")) 
    // whatever you want for save 
0

Je ne suis pas familier avec C#, mais it supports the conditional operator

condition ? first_expression : second_expression; 

Depuis que je ne suis pas familier avec C#, Je ne vais pas essayer de réécrire votre code, mais dans tous les cas, l'opérateur ternaire peut conduire à une concision agréable dans un endroit s.