Perché la (dimensione della posizione) è un modello prevalente in condizionali?

Lo schema più profondo è che usiamo naturalmente "[cosa che varia] [confronto] [cosa che non varia]" come ordine standard. Questo principio è valido per il tuo esempio perché la posizione può variare, mentre la dimensione no.

L'unica eccezione comune è quando si testano l'uguaglianza alcuni programmatori si allenano per usare l'ordine opposto (noto come condizioni Yoda ) per evitare il comune variable = constant piuttosto che variable == constant bug - Non tengo questa idea perché trovo molto più leggibile l'ordinamento naturale sopra descritto, principalmente perché è il modo in cui esprimiamo l'idea in inglese, e perché la maggior parte dei compilatori moderni lo rileveranno ed emetteranno un avvertimento.

L'unica giustificazione che abbia mai visto è che è come le linee del numero o altre cose che abbiamo imparato a scuola. Ad esempio, scriviamo righe numeriche come questa:

<--|--|--|--|--|--|-->
   1  2  3  4  5  6

Le cose più piccole appaiono a sinistra di cose più grandi. Lo stesso vale per altre cose come le date (pensa a come è strutturato un calendario).

In pratica si riduce a come pensiamo naturalmente all'ordine delle cose. È più facile leggere il primo modulo perché non devi fare molta elaborazione mentale su di esso.

Anche se è principalmente una questione di convenzioni, è mia opinione che questo corrisponda al modo in cui pensiamo, mostra l'elemento su cui poniamo l'accento.

Se li traduciamo in inglese, sarebbe la frase "Se la posizione è inferiore alla lunghezza dell'array", dove l'oggetto della frase è l'elemento transitorio.

Per esprimerlo in un altro modo, "se la lunghezza dell'array è maggiore della posizione" mette la lunghezza dell'array (assunta come valore fisso) nel soggetto e la posizione (transiente) diventa l'oggetto diretto.

La mia opinione, e questa è solo la mia opinione, è che è una convenzione per la leggibilità. Sebbene i due siano identici, si sentono diversi nel mio cervello. Non voglio sapere se la dimensione dell'array è maggiore di pos. Voglio sapere se pos è più piccola della dimensione dell'array.

È come una discussione mezzo vuoto vs mezzo pieno. Matematicamente identico, ma il mio cervello li vedrà in modo diverso a seconda del contesto.

Personalmente, se vedo

if (array.lengh > pos) {
    // do some with array[pos];
}

Inizierò a pensare se questo sia o meno un bug e cosa intendesse il programmatore. Sta cercando di fare qualcosa di diverso dai limiti di controllo?

Forse non sono brillante, ma se devo fare questo tipo di analisi su ogni riga di codice, mi fa male il cervello.

Per esprimere ciò che alcuni hanno cercato di ottenere, in un modo diverso ...

Quando l'ordine non fa alcuna differenza per il comportamento del programma, la differenza è chiaramente una questione di ciò che è più leggibile per gli umani. Ecco un motivo linguistico per cui la scelta di "argomento" a sinistra ha senso:

In linguistica, l'argomento di una frase è ciò di cui si parla, e il commento è ciò che viene detto sull'argomento. In questo esempio, possiamo supporre che position sia l'argomento e che "meno della lunghezza dell'array" sia il commento . In inglese e in molte altre lingue, l'argomento viene solitamente espresso prima del commento.
" La tendenza a posizionare inizialmente i componenti topicalizzati - inizialmente (fronting degli argomenti) è diffusa. "

Quindi una buona regola è quella di pensare alla tua linea di codice come una frase (o una clausola, in questo caso), decidere quale sia la frase di e metterla per prima se puoi . Spesso, la frase "about" sarà una variabile piuttosto che una costante. Ma a volte il commento anche coinvolge una variabile, quindi non puoi limitarti a quello.

È una combinazione di due cose, entrambe provenienti dall'assemblatore sottostante a cui sono state compilate le prime lingue (e molte di quelle attuali).

1. Gli array sono offset basati su zero in memoria (ad esempio, il primo blocco di dati si trova all'inizio del blocco di memoria allocato ... lo 0-index). Da qui l'uso di 0..n-1 per il pezzo variabile.

2. La ramificazione se un valore è inferiore a un altro valore (o registro, ecc.) è in genere una singola istruzione. Da qui l'uso dell'operatore meno-che (<).

Quindi, il pattern è passato dal vecchio assemblatore ad ANSI-C (che è più simile a un macro assemblatore in qualche modo) e da lì a Java e agli altri linguaggi simili a C.

Come molte altre risposte hanno detto, è molto più facile da leggere:

[thing that varies] [comparison] [thing that does not vary]

Quasi tutti quelli che conosco usano esclusivamente questo stile.

Esiste un'eccezione, per i linguaggi in stile C che utilizzano = per l'assegnazione e == per il confronto. Se accidentalmente digiti:

if (variable = 5) ...

invece di:

if (variable == 5) ...

quindi non riceverai un errore perché questa è una riga di codice valida. (Alcuni compilatori e IDE ti avvertiranno su come farlo, ma è ancora molto facile avere un errore di battitura così semplice.)

Tuttavia, se scrivi:

if (5 == variable) ...

il compilatore / interprete eseguirà un errore perché non è un costrutto valido (nella maggior parte delle lingue, comunque).

Questa commutazione è spesso definita Condizione Yoda .

UPDATE : ecco un elenco di luoghi in cui le condizioni di Yoda sono utili .

Personalmente, preferisco questo:

bool positionIsWithinBounds = pos < array.length;
if (positionIsWithinBounds) {
   // do some with array[pos];
}

... è più codice, ma è anche molto facile da leggere.

È una questione di preferenza o di convenzione. Se vuoi essere coerente, ci sono due modi ugualmente ragionevoli per farlo:

1. Metti sempre il "soggetto" per primo (pensalo come una frase) - il valore del test. Ad esempio, scriverebbe if (age>5)

2. O metti sempre prima l'elemento più piccolo (pensalo come i valori sono ordinati sullo schermo nell'ordine naturale). Quindi per esempio scriveresti if (a<b) indipendentemente dal fatto che questo codice sia per lo più su ao principalmente su b.

Entrambe le convenzioni raccomanderebbero il primo frammento che hai mostrato al posto del secondo, quindi suppongo che in questo caso particolare tu abbia la tua risposta. Direi che è consigliabile evitare di scrivere codice che viola entrambi (1) e (2) qui, poiché renderà più difficile la lettura per la maggior parte delle persone.