Che cosa significa "TILT" in un commento?

Sto leggendo Clean Code di Robert C. Martin e la frase TILTappare inspiegabilmente in alcuni esempi di codice. Esempio (è in Java, a proposito):

    ...
    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";
        ...
    }
    ...

Dal contesto, suppongo che TILTdesigna uno stato che è irraggiungibile e incluso solo per soddisfare il compilatore (ad esempio, nel codice sopra, TILTappare nel ErrorCode.OKcaso perché non dovrebbe esserci un messaggio di errore se lo stato è OK), ma Non ne sono sicuro.

Qualcuno sa cosa TILTsignifica / significa?

— Kyle Lin
fonte

Possibilmente risposta correlata su gaming.stackexchange.com

— rwong

Questo probabilmente si riferisce all'inclinazione del flipper, non dell'inclinazione del poker.

— Telastyn,

I flipper fisici dispongono di sensori che rilevano quando qualcosa all'esterno tenta di esercitare un'influenza eccessiva sul percorso della palla spingendo o inclinando la macchina. (Dico troppo qui perché il flipper ha una lunga tradizione di accettabilità di una certa quantità di movimento, specialmente quando la palla viene appesa a qualcosa.) Quando la macchina va in uno stato inclinato, tutto ciò che potrebbe segnare più punti per il giocatore è disabilitato fino a quando la palla cade dal fondo del tavolo. Questo di solito è accompagnato da una luce "Tilt" sul gioco e, talvolta, un segnale acustico di avvertimento. Pensalo come l'equivalente del flipper nel sollevare un'eccezione.

La metafora di Martin è tesa perché ErrorCode.OK, presumibilmente, è valida statuse non qualcosa che cerca di forzare la funzione a fare qualcosa che non dovrebbe. In altre parole, quell'input non sta cercando di ottenere la funzione per restituire il messaggio di errore per un argomento mancante.

Il resto non risponde alla tua domanda, ma può darti motivo di leggere il resto del libro con occhio critico. Non ho accesso al libro per vedere se il testo che circonda quell'esempio fa un cenno della mano, ma in caso contrario, il metodo fa cose che non sono all'altezza del titolo:

Il primo è che non tratta l'input o lo stato presumibilmente non valido come una condizione eccezionale e se ne lamenta. Se la documentazione del metodo dice che dovrebbe essere chiamato solo quando l'oggetto si statustrova in uno stato di errore, è chiaramente un problema logico nel codice chiamante che deve essere corretto.

Il secondo è che restituisce una stringa valida quanto una qualsiasi delle altre ma che funge effettivamente da costante magica. Un chiamante che desidera sapere se è stato un errore invocare il metodo dovrà controllare il contenuto del valore restituito o trasmetterlo alle persone che lo leggono per decifrare (ad es. Operation result:Senza ulteriori informazioni).

Un terzo facoltativo sarebbe che se il compilatore prevede una copertura completa dei valori enumerati, l'utilizzo defaultper catturare i casi non coperti è molto più leggibile rispetto al doverli enumerare singolarmente o in un gruppo. (Il lato filp è che potrebbe essere meglio far lamentare il compilatore in modo che l'aggiunta di un secondo stato, senza errori, costringerebbe il programmatore a dichiarare esplicitamente come dovrebbe essere gestito.)

— Blrfl
fonte

Non ho la mia copia di Clean Code a portata di mano, ma hai perso una quarta possibilità: che il metodo è solo una funzione di aiuto per generare un messaggio di errore leggibile per qualcosa come un oggetto di eccezione, che lo renderebbe perfettamente ragionevole così com'è , senza alcun "agitando la mano" richiesto.

— Doc Brown,

@DocBrown Questo è un punto giusto, anche se la prossima cosa da chiedersi sarebbe perché un oggetto di eccezione si permetta di essere costruito con uno stato non eccezionale.

— Blrfl,

FYI: Il classico sensore di inclinazione era un pendolo di metallo a cui era permesso oscillare liberamente all'interno dei confini di un anello di metallo. Urti la macchina aumenterebbe l'oscillazione del pendolo, e se avesse un contatto elettrico con l'anello, allora perdevi quella palla. Non urtare la macchina per un certo periodo di tempo consentirebbe all'oscillazione di spegnersi. Il pendolo non era visibile al giocatore: dovevi solo imparare, per tentativi ed errori, quanto urtava la macchina.

— Solomon Slow