GOTO est-il dans PHP evil?
J'ai récemment découvert que PHP 5.3 supporte une nouvelle construction de langage appelée GOTO. Tout le monde sait ce qu'il fait. Cependant, ce n'est pas exactement le traditionnel GOTO, c'est juste une étiquette de saut. Je suis intéressant de savoir si ce GOTO est mauvais et implique un mauvais code?
Sauf si vous programmez en assembleur, GOTO doit toujours être traité de la même manière que le gilet de sauvetage des avions: il est bon de les avoir à disposition, mais si vous devez les utiliser, cela signifie que vous êtes en grande difficulté.
Je ne peux pas croire que personne n'ait posté ça :)
Certes, PHP n'est pas compilé ... Peut-être que le raptor vous poursuivra à chaque visite sur votre site Web?
Une mauvaise structuration du code est mauvaise, quelle que soit la structure de contrôle que vous utilisez.
Personnellement, je préfère un goto qui indique clairement le flux du programme pour "contrôler les variables" et imbriqué "si" cela provoquera indirectement la même branche dans le code.
Donc, écrivez simplement les deux versions (avec et sans GOTO) et voyez laquelle est la plus facile à comprendre. Le choix est alors facile.
Je pense que c'est la partie la plus importante de la page de manuel PHP et qui manque ici:
Ce n'est pas un goto complet sans restriction . L'étiquette cible doit se trouver dans le même fichier et le même contexte, ce qui signifie que vous ne pouvez pas sauter hors d'une fonction ou d'une méthode, ni dans une . Vous ne pouvez pas non plus sauter dans aucune sorte de boucle ou de structure de commutateur. Vous pouvez sauter de ceux-ci, et une utilisation courante consiste à utiliser un goto à la place d'une pause à plusieurs niveaux.
À mon humble avis, cela le rend très différent des gotos de style ye olde BASIC.
Je suis en minorité (actuellement), mais je pense que les restrictions imposées à la construction goto de PHP en font un outil très bénéfique:
http://adamjonrichardson.com/2012/02/06/long-live-the-goto-statement/
En fait, je passe en revue un exemple de code de flèche (conditions profondément imbriquées) et le refactorise en utilisant des pratiques standard (clauses de garde, conditions de regroupement, fonctions d'extraction) dans une version et une version basée sur goto dans l'autre version, et je préfère en fait la refactoring basé sur goto.
Les armes sont-elles mauvaises? Les deux peuvent être utilisés pour le bien ou pour le mal. Je dirais qu'il était plus facile d'écrire du bon code sans goto qu'avec.
Toute fonctionnalité de langage qui peut rendre le code plus lisible dans une situation donnée est une bonne chose. GOTO est une de ces fonctionnalités linguistiques, même si ces situations sont rares. Si nous interdisions toute syntaxe permettant aux mauvais programmeurs d'écrire du code incorrect et non maintenable, nos tâches seraient beaucoup plus difficiles.
En tant qu'ingénieur logiciel, je travaille principalement sur les "mainframes" et les "gros serveurs d'entreprise" ... Et notre langage quotidien (je veux dire celui dans 95% de notre code de base) est le Cobol, qui utilise largement les GOTO.
Cette utilisation ne signifie pas que le code est mauvais. Cela signifie simplement que cet outil (GOTO) était le bon au moment où les programmes ont été écrits.
Pour répondre à la question de Kaitsuli, je pense que cela peut être un outil utile lors de l'écriture de scripts PHP. D'un autre côté, beaucoup de scripts ont été réalisés sans lui depuis près d'une décennie maintenant. contre l'évolution de PHP avec des fonctionnalités plus orientées objet.
À mon humble avis, ce n'est ni bon ni mauvais pour que le code soit produit: de bons programmes seront toujours bons et les "programmes d'horreur" seront pires ... La seule question est: "Pourquoi ajouter des GOTO 10 ans après avoir prouvé que ce n'était pas nécessaire? ".
GOTO est généralement mauvais parce qu'il vous permet de créer du code non structuré. Avec les boucles habituelles, vous pouvez créer un bon code structuré facile à suivre car il est structuré.
Lorsque vous avez du code non structuré qui saute d'ici à là, vous venez de découvrir le mal provenant de l'instruction GOTO. Il est presque toujours préférable de l'éviter. Peut-être qu'une fois toutes les 100 000 lignes, il y a un endroit où une phrase GOTO simplifie BEAUCOUP le code n'est donc pas mauvais mais si vous n'êtes pas sûr, alors vous devriez éviter le GOTO.
J'espère que cela t'aides.
EDIT: Eh bien, juste pour ajouter ma propre opinion ici, il existe d'autres instructions qui vous permettent de créer du code non structuré et qui ne sont pas considérées comme mauvaises quand je pense qu'elles devraient l'être.
Par exemple, un retour au milieu d'une fonction est un GOTO à la fin de celui-ci, donc je les évite et n'utilise qu'un seul retour dans chaque fonction juste à sa fin.
D'autres langues comme Vb.Net (peut-être d'autres aussi) permettent de faire Exit For, Exit While, des pauses et des choses comme celles-ci qui déstructurent également le code et je pense que cela devrait être évité.
parfois (je veux dire dans 0,01% des cas) c'est utile, comme quand vous avez un long script long et que vous voulez tester des blocs. mais ne le gardez jamais dans votre script final
J'ai utilisé GOTO lorsque j'écris un script pour travailler en mode cli. Cela m'a sauvé la vie.