"If (0 == value) ..." non fa più male che bene? [chiuso]


49

Questa è una delle cose che odio di più quando la vedo nel codice di qualcun altro. So cosa significa e perché alcune persone lo fanno in questo modo ("e se invece inserissi accidentalmente '=' invece?"). Per me è molto simile a quando un bambino scende le scale contando i passi ad alta voce.

Ad ogni modo, ecco i miei argomenti contrari:

  • Interrompe il flusso naturale di lettura del codice del programma. Noi umani diciamo "se il valore è zero" e non "se zero è valore".
  • I compilatori moderni ti avvisano quando hai un incarico nella tua condizione, o in realtà se la tua condizione è costituita solo da quell'incarico, che, sì, sembra comunque sospetto
  • Non dimenticare di mettere il doppio '=' quando confronti i valori se sei un programmatore. Potresti anche dimenticare di mettere "!" quando si verifica la non uguaglianza.

17
Neanche a me importa molto, ma è abbastanza in fondo alla mia lista personale di animali domestici.
Adam Crossland,

7
E a volte i programmatori mancano il doppio '='. È un errore facile da fare e molto facile da trascurare.
sange

8
In che modo questa non è costruttiva o non è una vera domanda?
TheLQ

7
Questo è chiuso, quindi ecco la mia breve opinione: come possono le persone ricordare di scrivere 0 == valuema non ricordare di scrivere ==?? Voglio dire blime, se ci stai pensando, perché non scriverlo correttamente per cominciare.
Dott. Annibale Lecter,

3
@muntoo: Secondo i compilatori, molte cose sono "corrette", non penso che sia un ottimo punto di riferimento.
Dott. Annibale Lecter,

Risposte:


59

Ah, sì, "Yoda conditionals" ("Se il valore è zero, eseguire questo codice è necessario!"). Indico sempre chiunque affermi di essere "migliore" con strumenti come lint (1). Questo particolare problema è stato risolto dalla fine degli anni '70. La maggior parte delle lingue moderne non compilerà nemmeno un'espressione simile if(x = 10), poiché si rifiuta di costringere il risultato dell'incarico a un booleano.

Come altri hanno già detto, non è certo un problema, ma provoca un po 'di dissonanza cognitiva.


32
+1 per "Yoda conditionals". In realtà ho LOL. :)
Bobby Tables,

3
Mentre l'ordinamento va bene, mi oppongo al confronto con zero invece del semplice cast booleano if(!value).
SF.

1
Quindi consideri le assegnazioni all'interno di un condizionale un errore?

4
"La maggior parte delle lingue moderne non lo compilerà nemmeno" Il problema si presenta quando si utilizza una lingua che costringe silenziosamente il risultato dell'assegnazione a un valore booleano. La lingua più popolare che mi viene in mente che fa questo sarebbe JavaScript. Questo è il motivo per cui utilizzo sempre i condizionali yoda anche in Java in modo da non dimenticare di farlo quando scrivo javascript. Cambio tra i due abbastanza spesso che può (ed è stato) un problema.
Sam Hasler,

3
Qualcuno sa di un compilatore che non verrà compilato if (0 == x)?
Kristopher Ives,

56

È odioso perché impone una piccola ma notevole tassa mentale.

Le persone leggono da sinistra a destra praticamente in tutti i linguaggi di programmazione (e nella maggior parte dei linguaggi naturali).

Se vedo 123 == x, il modo in cui analizzo mentalmente è:

  • 123- e allora? informazioni incomplete.
  • == - beh, 123 è 123, perché provarlo ...
  • x- ok, quindi è di questo che ci preoccupiamo. Solo ora ho il contesto.
  • Torna a riconsiderare 123e perché x viene confrontato con esso.

Quando vedo x == 123l'analisi mentale è:

  • x- Fornisce contesto, so qual è la condizione. Potrei scegliere di ignorare il resto. Sulla base del flusso precedente ho una buona idea del perché e di ciò che verrà (e sarei sorpreso se è diverso).
  • == - Così ho pensato.
  • 123 - Sì.

L'interruzione è piccola (in un semplice esempio), ma la noto sempre .

Indicare innanzitutto il valore può essere una buona idea se si desidera attirare l'attenzione su di esso, ad es if (LAUNCH_NUKES == cmd). Normalmente questa non è l'intenzione.


5
Esattamente. Nei linguaggi naturali la costante arriva sempre per lo stesso motivo: se la luce è rossa ...
mojuba,

2
@mojuba Vero, è quasi universale. Stranamente, ci sono alcuni linguaggi naturali in cui l'oggetto viene prima del soggetto (ordine OVS / OSV), ma sono tutti oscuri.
dbkk,

1
D'altra parte, alcuni di noi tendono a leggere i simboli prima della variabile. Sono più accattivanti. Quindi analizzerò =o ==prima 123o x, e finirò senza nemmeno preoccuparmi di tradurre il codice in inglese nella mia testa.
Izkata,

Inoltre, la maggior parte dei compilatori avviserà se richiesto correttamente, a meno che non si utilizzino parentesi graffe aggiuntive, quindi tenta di risolvere un problema.
Deduplicatore,

47

Dannoso? No. Funziona in entrambi i modi.

Cattiva pratica? Discutibile, nella migliore delle ipotesi. È una semplice programmazione difensiva.

Vale la pena perdere il sonno? Nah.


8
E quando lo leggo, capisco immediatamente il codice che è per me il motivo più importante per discutere uno stile di codifica. Sono totalmente d'accordo, non vale la pena perdere il sonno.
Jeff Siver,

17

Questo è fondamentalmente flaimbait.

No, non fa più male che bene. Semplice.

Più parole?

Argomento del compilatore? Ehm, ish, forse - non riporre troppa fiducia nel complier per salvarti da te stesso.

"Non dovresti dimenticare" - beh duh - no ovviamente non dovresti nel frattempo sono stanco, ho programmato tutto il giorno ho dovuto usare due lingue diverse e a volte, solo a volte, essendo umano faccio un errore.

Il punto di questo tipo di comportamento è che è difensivo, non è lì perché ti aspetti di sbagliare più di quanto hai un'assicurazione perché ti aspetti di schiantarti ... ma se fai il bello è essere coperto.

Difficile da leggere? Ti stai lamentando che un programmatore decente dovrebbe avere == cablato (il che rende tutti i tipi di ipotesi scadenti) ma che lo stesso programmatore decente non può leggere 0 == valore ??

Non fa male, ha potenziali benefici, domanda stupida, lascia che gli altri lo facciano se lo desiderano e vanno avanti.


6
Penso che il valore 0 == sia innaturale per coloro che hanno studiato l'algebra prima di studiare la programmazione.
Mojuba,

4
Non è questo il punto - sì, hai ragione, non legge bene ma ugualmente gran parte di ciò che noi, come programmatori, scriviamo non si accumula esattamente come linguaggio naturale ed è una questione di come interpreti cosa vedi
Murph,

4
Bravo .. Per non parlare del fatto che, poiché legge in modo innaturale, sei incline a prestare maggiore attenzione ad esso, cogliendo quindi potenziali errori.
mocj,

7
@mocj - Pertanto, dovremmo tutti programmare nel modo più ottuso possibile per garantire che le persone che leggono il nostro codice debbano davvero leggere il nostro codice?
Kaz Dragon,

6
@mocj - Lo apprezzo molto, ma la tua tesi è stata che la "balbuzie cerebrale" mentre stai leggendo il condizionale Yoda è una buona cosa. Sto ponendo la domanda che, in tal caso, dovremmo mirare a scrivere tutto il codice in modo da causare "balbuzie cerebrali"? Domanda genuina.
Kaz Dragon,

11

Non lo definirei dannoso, ma è odioso. Quindi no, non direi di si.


10

Non ho mai pensato che l'intero "e se dimenticassi un =?" mai avuto davvero molto peso. Sì, potresti fare un refuso, ma tutti facciamo errori di battitura, sembra sciocco cambiare l'intero stile di codifica perché hai paura di sbagliare. Perché non rendere tutte le variabili e le funzioni tutte minuscole senza punteggiatura, perché un giorno potresti dimenticare di capitalizzare qualcosa o dimenticare un carattere di sottolineatura?


5
Non è questo il punto della domanda, il punto è "è dannoso" - e non lo è. Un'irritazione molto minore nel peggiore dei casi, ma non dannosa.
Murph,

1
In linguaggi dinamici - assolutamente, potresti
digitare male

3
con tutto il rispetto, quando hai trascorso una notte tarda (o due) e scopri che la fonte (nel codice C ++) è a = anziché ==, avrebbe un certo peso.
DevSolo

2
@DevSolo: penso che dovrebbe davvero succedere una o due volte nella tua carriera, ma non di più
mojuba

9

Alcune persone lo usano per chiarire esattamente cosa sta facendo un condizionale. Per esempio:

Modo 1:

FILE *fp;

fp = fopen("foo.txt", "w+");
if (fp == NULL) {

Modo 2:

FILE *fp;

if (NULL == (fp = fopen("foo.txt", "w+"))) {

Alcune persone ritengono che il secondo esempio sia più conciso, o invertendo gli argomenti illustra il punto di un test (condizionale) prima del test stesso.

In tutta realtà, non mi dispiace affatto. Ho i miei cuccioli di pet riguardo allo stile e il più grande è l'incoerenza. Quindi, fallo allo stesso modo, in modo coerente e non mi dispiacerà leggere il tuo codice.

Mescolalo fino al punto in cui sembra che sei diverse persone con il loro stile distintivo ci abbiano lavorato contemporaneamente, mi annoio un po '.


4
Il secondo esempio mi ha fatto andare "eh?" Il primo è molto più leggibile. Ottimo esempio :)
Mateen Ulhaq,

6

Per me è un condizionamento semplice. Come qualcuno che ha imparato (negli anni '90) il C e il C ++, mi sono abituato e lo uso ancora, anche se le ragioni sono state insegnate.

Una volta che sei "condizionato" a cercare la "costante" sul lato sinistro, diventa una seconda natura.

Lo uso anche solo per equivalenza (o equivalenza negata), non per maggiore / minore di.

Sono completamente d'accordo con la risposta di Wonko.


5

L'unico caso in cui lo trovo utile è dove la parte variabile dell'if è piuttosto lunga e vedere i valori rende il codice più facile da leggere. Le lingue punteggiate dello spazio dei nomi ne offrono i migliori esempi.

Ad esempio, qualcosa su cui ho lavorato con Single Sign-On ha avuto una situazione in cui si potevano avere due sessioni simultanee se si fosse verificato un certo tipo di errore ed è stato recuperato in un certo modo, quindi devo aggiungere un gestore per esso che si trovava all'interno di un if che sembrava qualcosa come questo:

if (2 <= application.httpcontext.current.session["thenameofmysessiontoken"].items.count())

Certamente in questo esempio ci sono altri modi per farlo, ma questo sarebbe un caso in cui la versione numero primo è potenzialmente più leggibile.


2
Penso che la parola chiave qui sia "altri modi per farlo";)
mojuba

in questo caso sì, ma in alcuni casi questo è ancora il risultato più leggibile. Il mio unico punto è che ci sono alcuni motivi legittimi per farlo oltre a combattere il linguaggio e il comportamento e il tipo di ide
Bill

Ad essere sincero, ho difficoltà con le condizioni di Yoda per <= e> =. Il segno == è una questione diversa, perché nella mia testa posso solo cambiare i simboli, ma nel tuo caso devo ricordare che count () deve essere maggiore o uguale a 2, ed è piuttosto fastidioso derivare da un segno più piccolo o uguale.
Alex,

3

Eppure si verificano errori. E a volte vuoi un incarico in un operatore di loop in cui potresti altrimenti controllare l'uguaglianza, o almeno è pratica standard usarlo.

Lo sostengo in qualche modo. Il consiglio che ho seguito (possibilmente da Codice completo) è di mantenere nei confronti quello che dovrebbe essere il valore più basso a sinistra. Ne avevo discusso con un collega prima e pensava che fosse un po 'folle, ma mi sono abituato molto.

Quindi direi:

if ( 0 <= value )

Ma direi anche:

if ( value <= 100 )

Uguaglianza tenderò a verificare con la variabile a sinistra, tuttavia è solo più leggibile.


1
Sono abituato a usare if(y > x)tutto il tempo. A meno che non ysia una costante.
Mateen Ulhaq,

Lo facevo in quel modo, ma una volta che ho avuto l'idea di avere i valori più bassi sulla sinistra ho scoperto che il mio codice è molto più leggibile a colpo d'occhio.
glenatron,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.