Dans mon code, je dois pouvoir sauter (goto) un cas différent dans la même déclaration de commutation. Y a-t-il un moyen de faire cela?
Mon code est quelque chose comme ceci: (il y a beaucoup de code que je viens de laisser tout cela) } Merci pour votre temps!
-Jeff
4 Réponses :
C'est généralement Je pense qu'une solution plus lisible / maintenable serait de placer le code partagé dans une méthode et d'avoir plusieurs cas d'appel la méthode. si vous vraiment veux, vous pouvez utiliser Remarque: Je n'ai fourni que l'exemple de code ci-dessus pour répondre à votre question. Je me sens maintenant si sale, je pourrais avoir à acheter des Bad Code Offsets . goto pour faire quelque chose comme:
Merci. L'instruction de commutation est dans une méthode: - (ibaction) Showviewaction: (ID) Sender {Avisnumber = [Tag d'expéditeur]; Mais le cas # J'utilise est l'identifiant de la balise de l'expéditeur. Ainsi, lorsque l'utilisateur tapote un bouton avec la balise ID 500, la méthode utilise cette balise pour savoir dans quelle mesure utiliser l'utilisation.
Donc, cette méthode doit être énorme! Supprimer le code à partir du cas Les déclarations et les mettre dans d'autres méthodes pourraient rendre les choses plus faciles à lire. De plus, si vous avez un nombre statique de boutons, vous pouvez également associer chaque bouton à sa propre méthode à l'aide d'une action cible.
La façon dont j'avais l'habitude de faire était une méthode distincte pour chacun des cas et dans IB Tous les boutons étaient connectés à "Ibaction", mais mon patron estime que le code serait "plus fiable, élégant et exécuté plus vite" Si j'ai utilisé une instruction de commutation au lieu de méthodes distinctes. Vous dites donc qu'il serait préférable d'utiliser à nouveau des méthodes distinctes? J'ai aussi entendu parler avant que "goto" est mauvais à utiliser ... Savez-vous pourquoi c'est mauvais?
Il y a des tonnes de questions qui discutent de goto ( Stackoverflow.com/search?q=goto+bad ). Je pense que le commutateur est beaucoup moins élégant, surtout si certains boutons ne sont pas liés de quelque manière que ce soit. Il est beaucoup plus difficile de lire car il y a tellement de code dans un endroit qui n'est pas associé et pour chaque bouton, vous devez passer à travers un grand jeu de comparaisons pour trouver le bloc de cas correct. IMO, il vaut bien mieux que le bouton appelle simplement le code dont il a besoin que de passer à travers un "filtre" de commutateur comme celui-ci.
Vous ne devriez même pas penser à optimiser ce genre de choses que si vous avez des problèmes de performance et le profilage de la demande révèle que c'était la cause. Le nombre de nanosecondes économisés (si cela est encore plus rapide, que je doute) ne compensera pas les heures de maintenance qui y vont.
Au lieu de la rompre dans des méthodes distinctes que vous filez individuellement, la meilleure approche pourrait bien être laissée à laisser la méthode que vous avez (à un seul point à filer), mais comme d'autres suggèrent, prenez tout le code commun et mettez cela dans une méthode Vous appelez à partir de l'instruction Switch.
Je suis d'accord avec Kendall. Il se peut que l'énoncé de commutation soit bien, mais rompt toutes les parties communes dans les fonctions. Quant pourquoi Goto est considéré comme nocif, tout se résume à la lisibilité et au potentiel d'utilisation ultérieure / mauvaise utilisation. gotos rendent le code plus difficile à comprendre car vous devez sauter tout autour, et lorsque vous regardez une ligne de code, vous ne savez pas comment vous êtes arrivé là-bas ... [en général, "N'utilisez jamais des déclarations goto. Jamais" est l'un des Ces règles que vous ne devriez jamais casser; Sauf si vous comprenez pourquoi c'est une règle et peut donc le casser en toute sécurité.]
Vous devriez probablement essayer de réécrire votre code, comme un appel récursif ou simplement facteur de choses communes et appelez une fonction distincte. Mais comme solution et réponse rapide à votre question, vous pouvez mettre une étiquette avant votre interrupteur et le goto, comme pas sûr de la syntaxe de l'objectif-C ici, mais vous pouvez aussi essayer une variation de celui-ci qui continuera de boucler jusqu'à ce que le nombre d'images ne change plus. C'est toujours presque juste un joli goto. Et puisque nous faisons des gotos, vous pouvez simplement aller dans un autre cas, comme indiqué déjà. Vous pouvez également faire des trucs de fantaisie similaires à l'appareil de Duff, en mettant des cas à l'intérieur d'autres blocs. Mais c'est juste fou .. :)
au lieu d'utiliser quelque chose comme: < Pré> xxx Ce ne serait pas la fin du monde d'utiliser La raison pratique pour éviter l'utilisation de Si votre logique de commutation change, vous aurez une situation désordonnée sur vos mains. Si vous retirez le code commun à sa propre méthode, le code est plus facile à lire, débogage et s'étendre. goto , refacteur de votre code de sorte que les deux (ou plus) cas qui utilisent le code commun l'appellent à la place d'une méthode courante. goto , bien que ce soit une mauvaise pratique. goto est que vous devez rechercher dans votre swtich-case arbre pour trouver que goto étiquette.
[Je fais cette réponse wiki communautaire parce que cela ne répond pas à la question en soi]
Comme d'autres l'ont dit, c'est très mauvais style et crée un code illisible ...
Alternatives:
comme dans
NE PAS, ce serait une très mauvaise pratique de codage.
Cherchez-vous si une valeur frappe ou une autre, ils gèrent tous les deux le même cas de code? Si tel est le cas, vous pouvez simplement tomber au bon cas.
S'il vous plaît vous débarrasser de tous les accolades supplémentaires :(