Una variabile denominata i è inaccettabile? [chiuso]

https://stackoverflow.com/questions/130775

02-07-2019
|

Domanda

Per quanto riguarda le convenzioni di denominazione variabile, gli iteratori dovrebbero essere chiamati i o qualcosa di più semantico come count ? Se non usi i , perché no? Se ritieni che i sia accettabile, ci sono casi di iterazione in cui non dovrebbero essere utilizzati?

Soluzione

Dipende dal contesto suppongo. Se sei in loop attraverso una serie di oggetti in alcuni raccolta quindi dovrebbe essere abbastanza ovvio dal contesto che stai facendo.

for(int i = 0; i < 10; i++)
{
    // i is well known here to be the index
    objectCollection[i].SomeProperty = someValue;
}

Tuttavia, se non è immediatamente chiaro dal contesto cosa stai facendo, o se stai apportando modifiche all'indice, dovresti usare un nome di variabile che sia più indicativo dell'uso.

for(int currentRow = 0; currentRow < numRows; currentRow++)
{
    for(int currentCol = 0; currentCol < numCols; currentCol++)
    {
        someTable[currentRow][currentCol] = someValue;
    }
}

Altri suggerimenti

" i " significa " loop counter " a un programmatore. Non c'è niente di sbagliato in questo.

Ecco un altro esempio di qualcosa che va perfettamente bene:

foreach (Product p in ProductList)
{
    // Do something with p
}

Tendo a usare i, j, k per loop molto localizzati (esistono solo per un breve periodo in termini di numero di linee di origine). Per le variabili che esistono su un'area di origine più ampia, tendo a usare nomi più dettagliati in modo da poter vedere a cosa servono senza ricorrere al codice.

A proposito, penso che la convenzione di denominazione per questi venisse dal primo linguaggio Fortran in cui ero la prima variabile intera (A - H erano float)?

i è accettabile, certo. Tuttavia, ho imparato moltissimo un semestre da un insegnante di C ++ che avevo rifiutato il codice che non aveva un nome descrittivo per ogni singola variabile. Il semplice atto di nominare tutto in modo descrittivo mi ha costretto a pensare di più al mio codice e dopo quel corso ho scritto programmi migliori, non imparando il C ++, ma imparando a nominare tutto. Codice completo contiene alcune buone parole su questo stesso argomento.

i va bene, ma qualcosa del genere non lo è:

for (int i = 0; i < 10; i++)
{
    for (int j = 0; j < 10; j++)
    {
        string s = datarow[i][j].ToString(); // or worse
    }
}

Molto comune per i programmatori di scambiare inavvertitamente i e j nel codice, specialmente se hanno una vista negativa o il loro tema di Windows è "hot dog". Questo è sempre un "odore di codice" per me - è un po 'raro quando questo non viene rovinato.

i è così comune che è accettabile, anche per le persone che amano i nomi di variabili descrittive.

Ciò che è assolutamente inaccettabile (e un peccato nel mio libro) è usare i, j o ??k in qualsiasi altro contesto se non come un indice intero in un ciclo .... ad esempio

foreach(Input i in inputs)
{
    Process(i);

}

i è decisamente accettabile. Non sono sicuro del tipo di giustificazione che devo fornire, ma lo uso sempre, e lo fanno anche altri programmatori molto rispettati.

Convalida sociale, immagino :)

Sì, in effetti è preferito poiché qualsiasi programmatore che legge il tuo codice capirà che è semplicemente un iteratore.

Qual è il valore di usare i invece di un nome di variabile più specifico? Per risparmiare 1 secondo o 10 secondi o forse, forse, anche 30 secondi per pensare e scrivere?

Qual è il costo dell'utilizzo di i? Forse niente. Forse il codice è così semplice che l'utilizzo di i va bene. Ma forse, forse, usando costringerò gli sviluppatori che verranno in questo codice in futuro a pensare per un momento "cosa intendo qui?" Dovranno pensare: "è un indice, un conteggio, un offset, una bandiera?" Dovranno pensare: "questo cambiamento è sicuro, è corretto, sarò spento di 1?"

L'utilizzo di i consente di risparmiare tempo e sforzi intellettuali durante la scrittura del codice, ma potrebbe finire per costare un maggiore sforzo intellettuale in futuro, o forse anche comportare l'introduzione involontaria di difetti a causa di incomprensioni del codice.

In generale, la maggior parte dello sviluppo di software riguarda la manutenzione e l'estensione, quindi il tempo impiegato a leggere il codice supererà di molto il tempo impiegato a scriverlo.

È molto facile sviluppare l'abitudine di usare nomi significativi ovunque, e una volta che hai quell'abitudine ci vogliono solo pochi secondi in più per scrivere codice con nomi significativi, ma poi hai un codice che è più facile da leggere, più facile da capire e più ovviamente corretto.

Uso i per loop brevi.

Il motivo per cui è OK è che trovo assolutamente implausibile che qualcuno possa vedere una dichiarazione di tipo iteratore, con inizializzatore, e poi tre righe successive affermano che non è chiaro cosa rappresenti la variabile. Stanno solo fingendo, perché hanno deciso che "nomi variabili significativi" deve significare "quotazioni variabili lunghe".

Il motivo per cui lo faccio davvero, è che trovo che l'uso di qualcosa non correlato allo specifico compito da svolgere e che userei sempre e solo in un ambito limitato, mi fa preoccupare di poter usare un nome fuorviante, oppure ambiguo, o sarà utile un giorno per qualcos'altro nel campo più ampio. Il motivo è " i " piuttosto che " q " o "contare" è solo una convenzione presa in prestito dalla matematica.

Non uso i se:

Il corpo del loop non è piccolo o
l'iteratore fa altro che avanzare (o ritirarsi) dall'inizio di un intervallo alla fine del ciclo:

Non devo necessariamente andare con incrementi di 1 purché l'incremento sia coerente e chiaro, e ovviamente potrebbe fermarsi prima della fine dell'iterando, ma se cambia direzione o non viene modificato da un'iterazione del loop (incluso l'uso diabolico di iterator.insertAfter () in un loop forward), provo a ricordare di usare qualcosa di diverso. Questo segnala "non si tratta solo di una banale variabile ad anello, quindi potrebbe non essere un semplice banale".

Se il " qualcosa di più semantico " è "iteratore" quindi non c'è motivo di non usare i; è un linguaggio ben compreso.

Penso di essere completamente accettabile in situazioni for-loop. ho sempre trovato che questo era piuttosto standard e non ho mai incontrato problemi di interpretazione quando sono usato in questo caso. i foreach-loop diventano un po 'più complicati e penso che dipenda davvero dalla tua situazione. Raramente, se mai, lo uso in foreach, solo in for loop, in quanto trovo che in questi casi sia troppo descrittivo. per foreach provo ad usare un'abbreviazione del tipo di oggetto in loop. per esempio:

foreach(DataRow dr in datatable.Rows)
{
    //do stuff to/with datarow dr here
}

comunque, solo i miei $ 0,02.

Aiuta se lo chiami qualcosa che descrive ciò che sta attraversando. Ma di solito uso solo io.

Fintanto che stai usando i per contare i loop o parte di un indice che va da 0 (o 1 a seconda di PL) ad n, allora direi che sto bene.

Altrimenti è probabilmente facile nominare qualcosa di significativo, è più di un semplice indice.

Dovrei sottolineare che i e j sono anche notazioni matematiche per gli indici di matrice. E di solito, esegui il looping su un array. Quindi ha senso.

Fintanto che lo stai usando temporaneamente all'interno di un semplice ciclo ed è ovvio quello che stai facendo, certo. Detto questo, non c'è altra parola breve che puoi usare invece?

i è ampiamente noto come iteratore di loop, quindi in realtà hai maggiori probabilità di confondere i programmatori di manutenzione se lo usi al di fuori di un loop, ma se usi qualcosa di più descrittivo (come filecounter ), rende il codice più gradevole.

Dipende. Se stai ripetendo un determinato insieme di dati, penso che abbia più senso usare un nome descrittivo. (ad es. filecounter come Dan ha suggerito).

Tuttavia, se stai eseguendo un ciclo arbitrario, i è accettabile. Come mi ha descritto un compagno di lavoro - i è una convenzione che significa " questa variabile è sempre e solo modificata dal costrutto del ciclo for . Se ciò non è vero, non utilizzare i "

L'uso di i, j, k per i contatori di loop INTEGER risale ai primi giorni di FORTRAN.
Personalmente non ho problemi con loro fintanto che sono conteggi INTEGER.
Ma poi sono cresciuto su FORTRAN!

la mia sensazione è che il concetto di usare una sola lettera vada bene per "semplice". i loop, tuttavia, ho imparato a usare le doppie lettere molto tempo fa e ha funzionato alla grande.

ho fatto una domanda simile la settimana scorsa e quanto segue fa parte di la mia risposta :

// recommended style              ●    // "typical" single-letter style
                                  ●
for (ii=0; ii<10; ++ii) {         ●    for (i=0; i<10; ++i) {
    for (jj=0; jj<10; ++jj) {     ●        for (j=0; j<10; ++j) {
        mm[ii][jj] = ii * jj;     ●             m[i][j] = i * j;
    }                             ●        }
}                                 ●    }

nel caso in cui il vantaggio non sia immediatamente evidente: la ricerca nel codice di una singola lettera troverà molte cose che non sono ciò che stai cercando. la lettera i appare abbastanza spesso nel codice in cui non è la variabile che stai cercando.

Lo faccio da almeno 10 anni.

nota che molte persone hanno commentato che una o entrambe le precedenti sono "brutte" ...

Ho intenzione di andare contro il grano e dire di no.

Per la folla che dice "sono inteso come iteratore", ciò può essere vero, ma per me è l'equivalente di commenti come "Assegna il valore 5 alla variabile Y. I nomi di variabili come commento dovrebbero spiegare il perché / cosa non il come.

Per usare un esempio da una risposta precedente:

for(int i = 0; i < 10; i++)
{
    // i is well known here to be the index
    objectCollection[i].SomeProperty = someValue;
}

È molto più difficile usare un nome significativo come questo?

for(int objectCollectionIndex = 0; objectCollectionIndex  < 10; objectCollectionIndex ++)
{
    objectCollection[objectCollectionIndex].SomeProperty = someValue;
}

Concesso il nome (preso in prestito) della variabile objectCollection è anche abbastanza mal chiamato.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow