2010-06-02 4 views
9

Si une variable peut prendre n valeurs, nous devons vérifier la validité des valeurs ou supposer que si toutes les vérifications n-i échouent, ce sera la nième valeur.Quelle est la manière la plus appropriée de programmer

Par exemple, si nous avons une variable qui stocke le genre comme M ou F. Utilisez ceci:

If gender = "M" 
    do male_processing 
else 
    do female_processing 
endif 

Ou ceci:

If gender = "M" 
    do male_processing 
else 
    if gender = "F" 
    do female_processing 
    else 
    print "Something has gone wrong Gender has a value " Gender 
    endif 

endif 
+2

Lors de la publication ici, indentez votre code correctement et ensuite le formater avec le bouton 1010 au-dessus de la zone de saisie de texte. –

+0

Désolé je me suis rendu compte si après avoir frappé le soumettre. Merci beaucoup! – Raju

+1

Pendant ce temps, dans le monde réel, le genre n'est pas une valeur booléenne. Il y a beaucoup de gens genreque sur le marché. – TRiG

Répondre

1

Pour ce type de construction, j'aime utiliser l'instruction switch. Non pas parce qu'il est plus court (il n'est pas), mais il est plus facile à lire (à mon humble avis):

switch(gender) { 
    case "M": 
    doMaleSpecificStuff(); 
    break; 
    case "F": 
    doFemaleSpecificStuff(); 
    break; 
    default: 
    throw AnyError; 
} 
4

Peu de temps - qui dépend de quel type est la variable. Si c'est un booléen ou une énumération quelconque et qu'il n'y a pas d'autre valeur possible (y compris null), une simple clause else suffira.

Vous pouvez même ajouter un simple commentaire comme ceci:

if male: 
    do_male_stuff() 
else: #obviously female 
    do_female_stuff() 

Avoir quelque chose comme cela semble tout simplement faux:

bool = SOME_BOOLEAN_VALUE 
if bool: 
    do1() 
elif not bool: 
    do2() 
else: 
    huh() #?!?! 

Bottom line: ont une clause if/else/else if pour chaque scénario possible, mais pas plus de que, et le garder lisible.

0

Si une troisième valeur, autre que M ou F, est possible, vous devez utiliser la deuxième forme. Si la variable testée est d'un type qui ne peut prendre que les valeurs M et F, vous devez utiliser la première.

+0

Pas nécessairement. Si une valeur autre que M ou F est possible, il se peut qu'ils souhaitent que "do_female_stuff()" soit l'action par défaut - dans ce cas, vous ne voulez probablement que deux options ("M" ou * autre) *). Cependant, vous voudriez certainement commenter que c'est un défaut intentionnel. – hemp

+0

Je suis tellement content que vous n'ayez pas inclus une illustration de ceci. –

+0

@hemp Il est évident à partir du deuxième exemple de l'OP, qui est censé être congruent avec le premier, que ce n'est pas le cas. –

2

... ou, dans le monde OO, vous pouvez créer une classe de base, par exemple Gender et l'étendre avec les classes Male et Female. Au lieu d'assigner la valeur 'M' ou 'F' à une variable, vous pouvez assigner une instance de classe Homme ou Femme. Ensuite, appelez simplement une méthode spécifiée dans la classe de base, par exemple doGenderSpecificStuff(). Pas besoin d'if-elses là-bas.

+1

OP demande spécifiquement des clauses if-else. Bien sûr, cela peut être fait d'une manière OO, mais ce n'est pas la question. –

+0

Alors, quel est le point d'avoir si-autre ?? – VoodooChild

+1

@Yuval: Si l'OP trouve cette réponse inappropriée, je vais l'enlever. Mais s'il vous plaît laissez l'OP décider. – fish

10

Pour cet exemple, je ne voudrais pas utiliser le cas échéant, je soit utiliser SWITCH votre deuxième exemple

switch (gender) 
    case "M": 
     do male_processing 
     break 
    case "F": 
     do female_processing 
     break 
    default: 
     print "Something has gone wrong Gender has a value " Gender 
endswitch 

ou pour votre premier exemple, je voudrais simplement traiter les exceptions comme une erreur en utilisant ASSERT

assert (gender = "M" or gender = "F") 
+0

Toutes les langues ne peuvent pas 'switch' sur tous les types de variables ... Cependant, la plupart des langages ont des constructions if-else. –

+3

+1 - pas pour le commutateur, mais juste pour traiter le troisième cas. Vous - ** DEVRAIT ** traiter le troisième cas - peu importe si c'est un «ELSE», «DEFAULT», «ASSERT» ou si vous le faites. Vérifiez-le. Votre disciple/future auto vous remerciera. – Konerak

1

Si les valeurs de GENDRE ne peuvent être « M » ou « F », vous pouvez utiliser un assert pour que ce soit clair:

Assert(gender = "M" OR gender = "F") 
If gender = "M" 
    do male_processing 
else 
    do female_processing 
endif 
0

Lors de l'énumération des moyens de traiter les différentes formes possibles d'un type de données, vous devez utiliser modèle correspondant si votre langue prend en charge ou, si elle n'a pas, instruction switch (la correspondance de motif du pauvre). La raison principale de ceci est que, si le type de données est étendu avec plus de formes potentielles, vous voulez être averti au moment de la compilation d'une correspondance de modèle incomplète (ou d'une instruction switch). vous le saurez plus tôt que plus tard.

L'utilisation d'un cas par défaut, malheureusement, ces avantages défait, donc dans la plupart des situations, vous devriez préférer énumérer explicitement toutes les possibilités connues.

0

S'il y a une entrée utilisateur pour « F » ou « M » alors vous devriez menace 3 scénarios à savoir. F, M et autre. S'il n'y a aucune entrée de l'utilisateur, vous pouvez utiliser deux et avoir une valeur de bool. isMale for if instruction donc il serait beaucoup plus lisible.

1

Si vous utilisez le type alors il énuméré seulement les valeurs que vous attendez et vous ne devez pas traiter avec des valeurs inattendues du SI, seulement à l'affectation.

0

Essayez de vérifier les entrées et normaliser le plus rapidement possible, alors vous pouvez utiliser en toute sécurité la première option.

Si votre interface utilisateur permet à l'entrée de cette variable d'être quelque chose (par exemple une zone de texte), alors dans votre exemple, vous pouvez obtenir "M", "Homme", "Homme" ou "Männlich" "que possible des entrées honnêtes pour les hommes, avant même de considérer que quelqu'un pourrait offrir une réponse stupide. En vérifiant (et en normalisant) ces valeurs avant de les utiliser, vous pouvez offrir un retour plus réactif à l'utilisateur.

Si votre interface utilisateur contraint à un bouton radio, il est normalisé encore plus tôt. Si la valeur est extraite d'un type de magasin de données, il est possible, selon l'application, et votre connaissance de l'intégrité de cette banque de données, de vérifier la validité de l'enregistrement avant de agissant sur les valeurs détenues à l'intérieur.

Si la plupart des dossiers sont susceptibles de se conformer, et les actions que les différentes valeurs sont pas cher et appellent réversibles, j'utiliser la deuxième option, et jeter une exception si une valeur est inappropriée.

Questions connexes