Je travaillais dans une feuille de problèmes Python et j'ai répondu à la question suivante
Vous conduisez un peu trop vite et un policier vous arrête. Écrivez une fonction pour renvoyer l'un des 3 résultats possibles: "Pas de billet", "Petit billet" ou "Big Ticket". Si votre vitesse est de 60 ou moins, le Le résultat n'est "pas de billet". Si la vitesse est comprise entre 61 et 80 inclus, le Le résultat est "petit ticket". Si la vitesse est de 81 ou plus, le résultat est "grand Billet ". Sauf si c'est votre anniversaire (codé en tant que valeur booléenne dans le Paramètres de la fonction) - Le jour de votre anniversaire, votre vitesse peut être 5 plus élevé dans tous les cas. p> BlockQuote>
def caught_speeding(speed, is_birthday): if is_birthday: speeding = speed - 5 else: speeding = speed if speeding < 60: print("No ticket") if 60 < speeding <= 80: print("Small Ticket") if speeding > 80: print("Big Ticket")
5 Réponses :
Dans ce type de cas, si et elif réalisent la même chose logiquement, car seulement 1 des conditions de si elles seront vraies p>
Mais l'avantage supplémentaire en utilisant elif est que, si la condition si code> correspond déjà, les instructions Elif ne sont pas exécutées du tout. Cela augmente les performances et est également logique car vous n'avez pas besoin de vérifier d'autres conditions si l'on correspond déjà. P>
Eh bien, notez que votre solution est fausse, car elle omet tout cas pour vitesse code> étant 60. Un si ... elif ... elif ... ... Code> Structure partitions EM> Les possibilités: chaque possibilité tombe dans un seul et unique cas (ou, si le sinon code> est omis, au plus un cas). Si le partitionnement est souhaité, lequel il est souvent, une structure de si ... si ... si ... code> a deux fabriques: p>
vitesse <= 60 code> et 60 ... code> dans les cas si code>, nous modifions des variables, parfois des variables utilisées dans les conditions de test, ce qui peut rendre ultérieurement Si CODE> Les tests évaluent à vrai, même si nous voulons qu'ils soient faux. Le elif code> La construction évite cela. Li>
ul>
Merci, c'est très utile! Cela m'a permis de comprendre la logique derrière elle. Merci d'être patient avec moi à partir de moi.
Cela bouillirait à la performance en fonction des questions indiquées.
Si -> sinon si, mettrait fin à cette vérification une fois qu'une solution est trouvée. p>
Si -> Si -> Si vous feriez un chèque pour chaque occurrence de si, quels ensembles de données plus vastes ou plus complexes entraîneraient des problèmes de performances. p>
Vous pouvez écrire moins de code et être plus facile à lire + Améliorer votre vitesse de code:
def caught_speeding(speed, is_birthday):
if is_birthday:
speed -= 5
if speed <= 60:
print("No ticket")
elif <= 80:
print("Small Ticket")
else:
print("Big Ticket")
Voici une autre solution pour cela.
Si les conditions sont mutuellement exclusives, il serait idiot de conserver les conditions de test après que l'on ait été trouvé.
Bien sûr, il y a une raison.
Si CODE> /ELIF CODE> /sinon CODE> Les chaînes vont casser la première condition qui est remplie. Les autres conditions ne seront pas testées