Come verificare la parità? (0 == i) o (i == 0) [chiuso]

https://stackoverflow.com/questions/148298

02-07-2019
|

Domanda

Ok, sappiamo che le seguenti due righe sono equivalenti -

(0 == i)
(i == 0)

Inoltre, il primo metodo è stato incoraggiato in passato perché ciò avrebbe permesso al compilatore di dare un messaggio di errore se si fosse accidentalmente usato '=' invece di '=='.

La mia domanda è: nella generazione odierna di IDE piuttosto eleganti e compilatori intelligenti, mi consigliate ancora il primo metodo?

In particolare, questa domanda mi è venuta in mente quando ho visto il seguente codice -

if(DialogResult.OK == MessageBox.Show("Message")) ...

A mio avviso, non consiglierei mai quanto sopra. Qualche secondo parere?

Soluzione

Preferisco il secondo, (i == 0), perché mi sembra molto più naturale quando lo leggi. Chiedi alle persone ", hai 21 anni o più?", Non ", 21 anni è inferiore o uguale alla tua età? & Quot;

Altri suggerimenti

Non importa in C # se inserisci la variabile per prima o ultima, perché le assegnazioni non valutano un valore booleano (o qualcosa che è possibile eseguire il bool) quindi il compilatore rileva eventuali errori come " if (i = 0) EntireCompanyData.Delete () "

Quindi, almeno nel mondo C #, è una questione di stile piuttosto che di disperazione. E mettere la variabile per ultimo è innaturale per chi parla inglese. Pertanto, per un codice più leggibile, prima variabile.

Se hai un elenco di if che non possono essere rappresentati bene da un interruttore (a causa di una limitazione della lingua, forse), preferirei vedere:

if (InterstingValue1 == foo) { } else
if (InterstingValue2 == foo) { } else
if (InterstingValue3 == foo) { }

perché ti consente di vedere rapidamente quali sono i valori importanti che devi controllare.

In particolare, in Java trovo utile fare:

if ("SomeValue".equals(someString)) {
}

perché someString potrebbe essere nullo e in questo modo non otterrai mai una NullPointerException. Lo stesso vale se si confrontano costanti che si sa che non saranno mai nulle rispetto a oggetti che potrebbero essere nulli.

(0 == i)

Prenderò sempre questo. È vero che oggi la maggior parte dei compilatori non consente l'assegnazione di una variabile in un'istruzione condizionale, ma la verità è che alcuni lo fanno. Nella programmazione per il web oggi, devo usare una miriade di lingue su un sistema. Usando 0 == i, so sempre che l'istruzione condizionale sarà corretta e non mi affido al compilatore / interprete per rilevare l'errore. Ora, se devo passare da C # a C ++ o JavaScript, so che non dovrò rintracciare gli errori di assegnazione nelle istruzioni condizionali nel mio codice. Per qualcosa di così piccolo e per averlo fatto risparmiare così tanto tempo, è un gioco da ragazzi.

Ero convinto che l'opzione più leggibile (i == 0) fosse il modo migliore di procedere.

Quindi abbiamo avuto un bug di produzione (non mio per fortuna), in cui il problema era un bug di tipo ($ var = SOME_CONSTANT). I clienti hanno iniziato a ricevere e-mail destinate ad altri clienti. Anche dati di tipo sensibile.

Puoi obiettare che il Q / A avrebbe dovuto prenderlo, ma non l'hanno fatto, è una storia diversa.

Da quel giorno ho sempre spinto per la versione (0 == i). Rimuove sostanzialmente il problema. Sembra innaturale, quindi presti attenzione, quindi non commetti l'errore. Semplicemente non c'è modo di sbagliare qui.

È anche molto più facile capire che qualcuno non ha invertito l'istruzione if in una revisione del codice piuttosto che qualcuno che ha assegnato accidentalmente un valore in un if. Se il formato fa parte degli standard di codifica, la gente lo cerca. Le persone in genere non eseguono il debug del codice durante le revisioni del codice e l'occhio sembra scansionare su un (i = 0) rispetto a un (i == 0).

Sono anche un grande fan di java "Constant String" .equals (dynamicString), nessuna eccezione al puntatore null è una buona cosa.

Sai, io uso sempre il formato if (i == 0) del condizionale e la mia ragione per farlo è che scrivo la maggior parte del mio codice in C # (che segnalerebbe l'altro uno comunque) e seguo un approccio test-first al mio sviluppo e i miei test generalmente colpiranno comunque questo errore.

Ho lavorato in negozi in cui hanno cercato di imporre il formato 0 == i, ma ho trovato imbarazzante scrivere, imbarazzante da ricordare e ha finito per essere semplicemente un foraggio per i revisori del codice che stavano cercando frutta a basso consumo .

In realtà, l'esempio di DialogResult è un posto in cui consiglierei questo stile. Posiziona la parte importante dell'if () verso sinistra dove può essere visto. Se è sulla destra e MessageBox ha più parametri (che è probabile), potresti dover scorrere verso destra per vederlo.

OTOH, non ho mai visto molto uso in " (0 == i) " stile. Se ricordi di mettere la costante al primo posto, puoi ricordare di usare due segni di uguale,

Sto provando ad usare sempre il primo caso (0 == i), e questo mi ha salvato la vita un paio di volte!

Penso che sia solo una questione di stile. E aiuta con l'uso accidentale dell'operatore di assegnazione.

Non vorrei assolutamente chiedere al programmatore di crescere.

Preferisco (i == 0), ma continuo a creare una "regola" " per me stesso fare (0 == i), e poi romperlo ogni volta.

" Eh? " ;, pensi.

Bene, se sto prendendo una decisione consapevole di mettere un valore a sinistra, allora sto prestando abbastanza attenzione a ciò che sto digitando per notare se scrivo " = " per " == " ;. Io spero. In C / C ++ generalmente utilizzo -Wall per il mio codice, che genera un avviso su gcc per la maggior parte di " = " per " == " errori comunque. Non ricordo di aver visto quell'avvertimento di recente, forse perché più a lungo programma più riflessivamente paranoico sono gli errori che ho commesso prima ...

if(DialogResult.OK == MessageBox.Show("Message"))

mi sembra fuorviato. Il punto del trucco è evitare l'assegnazione accidentale a qualcosa.

Ma chi può dire se DialogResult.OK ha più o meno probabilità di valutare un tipo assegnabile rispetto a MessageBox.Show (" Message ")? In Java non è possibile assegnare una chiamata al metodo, mentre un campo potrebbe non essere definitivo. Quindi, se sei preoccupato di digitare = per ==, in questo caso dovrebbe essere esattamente il contrario di Java. In C ++, nessuno dei due o entrambi potrebbero essere assegnabili.

(0 == i) è utile solo perché sai per certo che un letterale numerico non è mai assegnabile, mentre io potrei esserlo.

Quando entrambi i lati del tuo confronto sono assegnabili, non puoi proteggerti dall'assegnazione accidentale in questo modo, e questo vale quando non sai quale è assegnabile senza cercarlo. Non esiste un trucco magico che dice "se li metti in modo controintuitivo, sarai al sicuro". Anche se suppongo che attiri l'attenzione sul problema, allo stesso modo in cui il mio "infrange sempre la regola" regola.

Uso (i == 0) per il semplice motivo che legge meglio. Fa un flusso molto regolare nella mia testa. Quando rileggi il codice per te stesso per il debug o altri scopi, scorre semplicemente come leggere un libro e ha più senso.

La mia azienda ha appena abbandonato l'obbligo di fare se (0 == i) dai suoi standard di codifica. Vedo come ha molto senso, ma in pratica sembra solo al contrario. È un peccato che per impostazione predefinita un compilatore C probabilmente non ti avvertirà se (i = 0).

Terza opzione: non consentire del tutto l'assegnazione all'interno dei condizionali:

In situazioni di elevata affidabilità, non è consentito (senza una buona spiegazione nei commenti precedenti) assegnare una variabile in un'istruzione condizionale - elimina completamente questa domanda perché la si disattiva al compilatore o con LINT e solo sotto situazioni molto controllate ti è permesso di usarlo.

Tieni presente che generalmente viene generato lo stesso codice indipendentemente dal fatto che l'assegnazione avvenga all'interno del condizionale o all'esterno: è semplicemente una scorciatoia per ridurre il numero di righe di codice. Ci sono sempre delle eccezioni alla regola, ma non deve mai essere nel condizionale - puoi sempre evadere se necessario.

Quindi un'altra opzione è semplicemente quella di non consentire tali dichiarazioni e, se necessario, utilizzare i commenti per disattivare il controllo LINT per questo errore comune.

-Adam

Direi che (i == 0) sembrerebbe più naturale se tu provassi a pronunciare una riga in un inglese semplice (e ambiguo). Dipende molto dallo stile di programmazione del programmatore o dagli standard a cui sono tenuti ad aderire.

Personalmente non mi piace (1) e sempre (2), tuttavia ciò si inverte per leggibilità quando si tratta di finestre di dialogo e altri metodi che possono essere molto lunghi. Non sembra male come non è, ma se si espande MessageBox per tutta la sua lunghezza. Devi scorrere fino in fondo per capire quale tipo di risultato stai restituendo.

Quindi, mentre sono d'accordo con le tue affermazioni sul confronto semplicistico dei tipi di valore, non penso necessariamente che dovrebbe essere la regola per cose come le finestre di messaggio.

entrambi sono uguali, anche se preferirei leggermente la variante 0 == i.

quando si confrontano le stringhe, è più soggetto a errori confrontare " MyString " .equals (getDynamicString ())

poiché getDynamicString () potrebbe restituire null. per essere più attento, scrivi 0 == i

Bene, dipende dalla lingua e dal compilatore in questione. Il contesto è tutto.

In Java e C #, l'assegnazione "invece del confronto" l'errore di battitura finisce con un codice non valido a parte la rarissima situazione in cui si stanno confrontando due valori booleani.

Riesco a capire perché uno potrebbe voler usare il "quot" sicuro " modulo in C / C ++ - ma francamente, la maggior parte dei compilatori C / C ++ ti avvertirà se fai comunque l'errore di battitura. Se stai usando un compilatore che non lo fa, dovresti chiederti perché :)

Il secondo modulo (variabile quindi costante) è più leggibile dal mio punto di vista - quindi ovunque che sicuramente non causerà un problema, lo uso.

La regola 0 per tutti gli standard di codifica dovrebbe essere "scrivere codice che può essere letto facilmente da un altro essere umano." Per questa ragione vado con (valore che cambia più rapidamente) test-contro (valore che cambia meno rapidamente o costante), vale a dire "i == 0". in questo caso.

Anche laddove questa tecnica sia utile, la regola dovrebbe essere "evitare di mettere un valore a sinistra del confronto", piuttosto che "mettere sempre una costante a sinistra", che è come viene generalmente interpretata - per ad esempio, non c'è nulla da guadagnare dalla scrittura

if (DateClass.SATURDAY == dateObject.getDayOfWeek())

se getDayOfWeek () restituisce comunque una costante (e quindi non un valore)!

Sono fortunato (almeno in questo senso) in questi giorni in quanto sto principalmente scrivendo codice in Java e, come è stato detto, se (someInt = 0) non verrà compilato.

L'avvertenza sul confronto tra due booleani è un po 'un'aringa rossa, poiché la maggior parte delle volte stai confrontando due variabili booleane (nel qual caso scambiarle attorno non aiuta) o testare se è impostato un flag e guai se ti sorprendo a confrontare qualcosa di esplicitamente con vero o falso nei tuoi condizionali! Grrrr!

In C, sì, ma dovresti già aver attivato tutti gli avvisi e compilare senza avvisi, e molti compilatori C ti aiuteranno a evitare il problema.

Raramente vedo molti benefici da un POV di leggibilità.

La leggibilità del codice è una delle cose più importanti per il codice più grande di qualche centinaio di righe e sicuramente i == 0 legge molto più facilmente del contrario

Forse non è una risposta alla tua domanda. Provo a usare === (controllando identici) invece di uguaglianza. In questo modo non viene eseguita alcuna conversione del tipo e si impone al programmatore di assicurarsi che venga passato il tipo giusto,

Hai ragione sul fatto che posizionare prima il componente importante aiuta la leggibilità, poiché i lettori tendono a navigare principalmente nella colonna di sinistra e fornire informazioni importanti aiuta a far sì che vengano notate.

Tuttavia, non parlare mai a un collega, e sottintendere che sarebbe la tua azione anche per scherzo non ti farà ottenere voti alti qui

Vado sempre con il secondo metodo. In C #, scrivendo

if (i = 0) {
}

genera comunque un errore del compilatore (impossibile convertire int in bool), in modo che si possa fare un errore non è in realtà un problema. Se testate un bool, il compilatore sta ancora emettendo un avviso e non dovreste confrontare un bool con vero o falso. Ora sai perché.

Preferisco personalmente l'uso del formato a valore di operando variabile in parte perché lo uso da così tanto tempo che mi sembra "naturale" e in parte perché sembra la convenzione predominante. Esistono alcune lingue che fanno uso di dichiarazioni di assegnazione come le seguenti:

:1 -> x

Quindi nel contesto di quelle lingue può diventare abbastanza confuso vedere quanto segue anche se è valido:

:if(1=x)

Quindi anche questo è qualcosa da considerare. Concordo sul fatto che la risposta alla finestra di messaggio sia uno scenario in cui l'utilizzo di un formato variabile valore-operando funziona meglio dal punto di vista della leggibilità, ma se stai cercando costanza, dovresti rinunciare al suo utilizzo.

Questo è uno dei miei più grandi animali domestici. Non vi è alcun motivo per ridurre la leggibilità del codice (se (0 == i), cosa? Come può cambiare il valore di 0?) Per catturare qualcosa che qualsiasi compilatore C scritto negli ultimi vent'anni può catturare automaticamente.

Sì, lo so, la maggior parte dei compilatori C e C ++ non lo attiva per impostazione predefinita. Cerca l'interruttore corretto per accenderlo. Non ci sono scuse per non conoscere i tuoi strumenti.

Mi dà davvero sui nervi quando lo vedo strisciare in altre lingue (C #, Python) che normalmente lo segnalano comunque!

Credo che l'unico fattore che possa mai forzare l'uno sull'altro è se la catena di strumenti non fornisce avvisi per catturare i compiti nelle espressioni. Le mie preferenze come sviluppatore sono irrilevanti. Un'espressione viene meglio servita presentando chiaramente la logica aziendale. Se (0 == i) è più adatto di (i == 0) lo sceglierò. Altrimenti sceglierò l'altro.

Molte costanti nelle espressioni sono rappresentate da nomi simbolici. Alcune guide di stile limitano anche le parti del discorso che possono essere utilizzate per gli identificatori. Li uso come guida per aiutare a modellare il modo in cui l'espressione legge. Se l'espressione risultante legge vagamente come pseudo codice, di solito sono soddisfatto. Lascio semplicemente che l'espressione si esprima e, se sbaglio, di solito viene catturato da una revisione tra pari.

Potremmo andare avanti all'infinito su quanto sono diventati buoni i nostri IDE, ma sono ancora scioccato dal numero di persone che abbassano i livelli di avviso sul loro IDE.

Quindi, per me, è sempre meglio chiedere alle persone di usare (0 == i), come non si sa mai, quale programmatore sta facendo cosa. È meglio essere "sicuri che dispiaciuti"

if(DialogResult.OK == MessageBox.Show("Message")) ...

Consiglierei sempre di scrivere il confronto in questo modo. Se il risultato di MessageBox.Show (" Message ") può eventualmente essere nullo, rischi un NPE / NRE se il confronto è il contrario.

Le operazioni matematiche e logiche non sono riflessive in un mondo che include NULL.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow