Que signifie «TILT» dans un commentaire?

Je lis Clean Code par Robert C. Martin, et la phrase TILTapparaît inexplicablement dans certains exemples de code. Exemple (c'est en Java, soit dit en passant):

    ...
    public String errorMessage() {
      switch (status) {
        case ErrorCode.OK:
          // TILT - Should not get here.
          return "";
        case ErrorCode.UNEXPECTED_ARGUMENT:
          return "Unexpected argument";
        case ErrorCode.MISSING_ARGUMENT:
          return "Missing argument";
        ...
    }
    ...

Du contexte, je suppose que TILTdésigne un état qui est inaccessible et uniquement inclus pour satisfaire le compilateur (par exemple, dans le code ci-dessus, TILTapparaît dans le ErrorCode.OKcas car il ne devrait pas y avoir de message d'erreur si l'état l'est OK), mais Je ne suis pas sûr.

Quelqu'un sait-il ce que TILTsignifie / signifie?

Les flippers physiques ont des capteurs qui détectent quand quelque chose à l'extérieur essaie d'exercer trop d'influence sur la trajectoire de la balle en poussant ou en inclinant la machine. (J'en dis trop ici parce que le flipper a une longue tradition selon laquelle une certaine quantité de mouvement est acceptable, surtout lorsque le ballon est accroché à quelque chose.) Lorsque la machine passe à l'état incliné, tout ce qui pourrait marquer plus de points au joueur est désactivé jusqu'à ce que le ballon tombe du bas de la table. Ceci est généralement accompagné d'un voyant "Tilt" sur le jeu et parfois d'un buzzer d'avertissement. Considérez-le comme l'équivalent du flipper de lever une exception.

La métaphore de Martin est tendue parce que ErrorCode.OKc'est, vraisemblablement, une statuschose valide et non quelque chose qui essaie de forcer la fonction à faire quelque chose qu'elle ne devrait pas. En d'autres termes, cette entrée n'essaie pas d'obtenir la fonction pour renvoyer le message d'erreur pour un argument manquant.

Le reste de cela ne répond pas à votre question, mais cela peut vous donner une raison de lire le reste du livre avec un œil critique. Je n'ai pas accès au livre pour voir si le texte entourant cet exemple fait un signe de la main, mais sinon, la méthode fait des choses qui ne sont pas à la hauteur du titre:

Premièrement, il ne traite pas les entrées ou états présumés non valides comme une condition exceptionnelle et s'en plaint. Si la documentation de la méthode indique qu'elle ne doit être appelée que lorsque l'objet statusest dans un état d'erreur, c'est clairement un problème logique dans le code appelant qui doit être corrigé.

Deuxièmement, il renvoie une chaîne qui est tout aussi valide que les autres, mais sert en fait de constante magique. Un appelant qui veut savoir si l'invocation de la méthode était une erreur devra vérifier le contenu de la valeur de retour ou la transmettre allègrement à l'humain qui la lit pour la déchiffrer (par exemple, Operation result:sans information supplémentaire).

Un troisième optionnel serait que si le compilateur s'attend à une couverture complète des valeurs énumérées, l'utilisation defaultpour intercepter les cas non couverts est beaucoup plus lisible que d'avoir à les énumérer individuellement ou en groupe. (Le côté filp est qu'il pourrait être préférable de laisser le compilateur se plaindre afin que l'ajout d'un deuxième statut sans erreur oblige le programmeur à déclarer explicitement comment il doit être géré.)