Devo sacrificare nomi di variabili più brevi per un codice "a colonna" più lungo?

Sono un programmatore amatoriale in una classe CS che cerca di imparare le abilità di programmazione adeguate. Ecco come appare il mio codice, i suoi bordi si estendono a 103 colonne.

int extractMessage(char keyWord[25], char cipherText[17424],
                   int rowSize, char message[388]) 
{
    int keyColumn    = 0;
    int cipherColumn = 0;
    int offset       = 1;
    int nextWord     = 1;

    int lengthOfWord   = 0;
    int lengthOfCipher = 0;

    lengthOfWord = length(keyWord);
    lengthOfCipher = length(cipherText);


    while (keyWord[keyColumn] != cipherText[cipherColumn]) {
        cipherColumn++;
        if (keyWord[keyColumn + offset] != cipherText[cipherColumn + (rowSize*nextWord) + nextWord]) {
            cipherColumn++;
            continue;
        }
    }

Prima che avessi quei nomi di variabili super lunghi avevo cose come me, j, k, ma il mio professore insiste sul fatto che non dovremo usare variabili del genere nel "mondo professionale" e che anche le variabili abbreviate come lenWord sono insufficienti perché le persone potrebbero presumere sta per "Lennard's World Literature". Dice di scegliere nomi di variabili significativi, ma così facendo mi sento come se avessi infranto la Regola d'oro del codice per tenerlo sotto 80 colonne. Come posso aggirare questo?

Normalmente quando vedo un codice pubblicato qui come il tuo, lo modifico, perché odiamo lo scorrimento orizzontale. Ma poiché fa parte della tua domanda, ti mostrerò la modifica qui:

int extractMessage(char keyWord[25], char cipherText[17424],
                   int rowSize, char message[388]) 
{
    int keyColumn    = 0;
    int cipherColumn = 0;
    int offset       = 1;
    int nextWord     = 1;

    int lengthOfWord   = 0;
    int lengthOfCipher = 0;

    lengthOfWord = length(keyWord);
    lengthOfCipher = length(cipherText);


    while (keyWord[keyColumn] != cipherText[cipherColumn]) {
        cipherColumn++;
        if (keyWord[keyColumn + offset] 
        != cipherText[cipherColumn + (rowSize*nextWord) + nextWord]) {
            cipherColumn++;
            continue;
        }
    }
}

Quella pausa può essere sorprendente, ma è più leggibile rispetto alla versione con scorrimento orizzontale, ed è meglio che accorciando i nomi da i, je k.

Non è che non si dovrebbe mai usare i, je k. Questi sono nomi validi quando si indicizzano 3 forloop nidificati . Ma qui i nomi sono davvero il mio unico indizio su cosa ti aspettavi che accadesse. Soprattutto perché questo codice in realtà non fa nulla.

La migliore regola da seguire sulla lunghezza del nome della variabile è l'ambito. Più a lungo vive una variabile, più altre variabili con cui il suo nome deve competere. Il nome CandiedOrange è unico nello scambio di stack. Se fossimo in chat, potresti semplicemente chiamarmi "Candy". Ma in questo momento, sei in un ambito in cui quel nome potrebbe essere confuso con Candide , Candy Chiu o Candyfloss . Quindi più lungo è l'ambito, più lungo dovrebbe essere il nome. Più breve è l'ambito, più breve può essere il nome.

La lunghezza della linea non dovrebbe mai dettare la lunghezza del nome. Se ne hai voglia, trova un modo diverso di strutturare il tuo codice. Abbiamo molti strumenti per aiutarti a farlo.

Una delle prime cose che cerco è il rumore inutile per sbarazzarsi di. Purtroppo questo esempio non fa nulla, quindi è tutto rumore inutile. Ho bisogno di qualcosa con cui lavorare, quindi prima facciamolo fare qualcosa.

int calcCipherColumn(char keyWord[25], char cipherText[17424],
                     int rowSize, char message[388]) 
{
    int keyColumn    = 0;
    int cipherColumn = 0;
    int offset       = 1;
    int nextWord     = 1;

    int lengthOfWord   = 0;
    int lengthOfCipher = 0;

    lengthOfWord = length(keyWord);
    lengthOfCipher = length(cipherText);

    while (keyWord[keyColumn] != cipherText[cipherColumn]) {
        cipherColumn++;
        if (keyWord[keyColumn + offset] 
        != cipherText[cipherColumn + (rowSize*nextWord) + nextWord]) {
            cipherColumn++;
            continue;
        }
    }
    return cipherColumn;
}

Ecco, ora fa qualcosa.

Ora che fa qualcosa, posso vedere di cosa posso liberarmi. Questa roba non è nemmeno usata. continueNeanche questo fa nulla.

int calcCipherColumn(char keyWord[25], char cipherText[17424],
                     int rowSize, char message[388]) 
{
    int keyColumn    = 0;
    int cipherColumn = 0;
    int offset       = 1;
    int nextWord     = 1;

    while (keyWord[keyColumn] != cipherText[cipherColumn]) {
        cipherColumn++;
        if (keyWord[keyColumn + offset] 
        != cipherText[cipherColumn + (rowSize*nextWord) + nextWord]) {
            cipherColumn++;
        }
    }
    return cipherColumn;
}

Facciamo alcune piccole modifiche agli spazi bianchi, perché viviamo in un mondo di controllo del codice sorgente ed è bello quando l'unica ragione per cui una riga viene segnalata come cambiata è perché sta facendo qualcosa di diverso, non perché una parte di essa doveva essere allineata in una colonna.

int calcCipherColumn(char keyWord[25], char cipherText[17424],
                     int rowSize, char message[388]) 
{
    int keyColumn = 0;
    int cipherColumn = 0;
    int offset = 1;
    int nextWord = 1;

    while (keyWord[keyColumn] != cipherText[cipherColumn]) {
        cipherColumn++;
        if (keyWord[keyColumn + offset] 
        != cipherText[cipherColumn + (rowSize*nextWord) + nextWord]) {
            cipherColumn++;
        }
    }
    return cipherColumn;
}

Sì, lo so che è leggermente meno leggibile, ma altrimenti farai impazzire le persone che usano gli strumenti vdiff per rilevare le modifiche.

Ora risolviamo queste sciocche interruzioni di linea che abbiamo perché stiamo cercando di rimanere sotto i limiti di lunghezza della linea.

int calcCipherColumn(
        char keyWord[25], 
        char cipherText[17424],
        int rowSize, 
        char message[388]
) {
    int keyColumn = 0;
    int keyOffset = 1;

    int nextWord = 1;
    int cipherColumn = 0;
    int cipherOffset = (rowSize * nextWord) + nextWord;

    char key = keyWord[keyColumn];
    char keyNext = keyWord[keyColumn + keyOffset];

    while (key != cipherText[cipherColumn]) {
        cipherColumn++;
        if (keyNext != cipherText[cipherColumn + cipherOffset]) {
            cipherColumn++;
        }
    }
    return cipherColumn;
}

Lì, ora la logica nel loop è focalizzata su ciò che cambia nel loop. In effetti, tutto tranne cipherColumnpotrebbe essere contrassegnato final. Ehi! Guarda quello. Ora abbiamo spazio per farlo.

Tutto quello che ho fatto è stato aggiungere altre 3 variabili, rinominarne una e riordinarle un po '. E il risultato è appena arrivato a rendere le linee abbastanza corte da adattarsi senza una sciocca interruzione !=.

Sicuramente i nomi keye keyNextnon sono così descrittivi, ma ognuno di essi si abitua solo una volta, non vive così a lungo e, cosa più importante, non sta facendo nulla di così interessante nel ciclo. Quindi non hanno bisogno di essere. Introducendo variabili extra, ora abbiamo spazio per rendere lunghi i loro nomi, se necessario. Le cose cambiano, quindi alla fine potremmo averne bisogno. Se lo facciamo, è bello avere spazio per respirare.

Mi sono anche preso la libertà di mostrarti lo stile variante 6 di Jeff Grigg per la disposizione dei parametri di input per rispettare le restrizioni sulla lunghezza della linea.

Altri hanno già dato alcuni suggerimenti utili, vorrei riassumere:

• 80 caratteri per riga potrebbero essere stati una regola d'oro negli anni '80. Oggi la maggior parte delle persone concorda sul fatto che 100-130 caratteri vanno bene.
• Usa le interruzioni di riga all'interno delle tue espressioni.
• Dividi lunghe espressioni introducendo risultati intermedi.

Mi piace aggiungere un'altra raccomandazione: non essere dogmatico sui nomi lunghi! Maggiore è l'ambito di una variabile, più informazioni devono essere inserite nel suo nome. E in genere è una buona idea mantenere piccolo l'ambito delle variabili.

Ad esempio, se si dispone di una variabile per la colonna della tabella di crittografia delle parole chiave ed è chiaro che esiste solo questa tabella utilizzata nell'ambito della variabile, è possibile chiamarla columno addirittura col. Se l'ambito è più ampio e ci sono più tabelle coinvolte, ha senso chiamarlo keyWordEncryptionTableColumn.

Un altro esempio: se hai un ciclo con un corpo che si estende su due o tre linee e devi usare un indice per accedere agli elementi di un array, non c'è nulla di sbagliato nel chiamare l'indice i. In questo contesto è molto più leggibile (almeno per la maggior parte delle persone) di, diciamo arrayIndexOfMyVerySpecialDataSet.

Sono generalmente d'accordo con te insegnante. Tuttavia, se si dispone di una variabile che si intende utilizzare molto in un pezzo di codice di grandi dimensioni non riuscito, può essere meglio utilizzare una forma abbreviata per esso dopo essere stato esplicito sul suo significato. Come quando si hanno molte espressioni e compiti aritmetici complessi, quelli non leggono bene con nomi di variabili lunghe.

A proposito di delineare:

ExtractMessage(char keyWord[25], char cipherText[17424],
               int rowSize, char message[388]) 

Questo non serve a nulla, limitando la lunghezza della linea non lo rende più leggibile. Se vuoi che sia leggibile, fai come segue:

ExtractMessage(
  char keyWord[25],
  char cipherText[17424],
  int rowSize,
  char message[388]
  )
{

E quindi potresti anche voler allineare gli identificatori di tipo (aggiungi uno spazio dopo int). Tuttavia, stai attento / restrittivo nel delineare initalizzazioni o elenchi di argomenti come questo:

int keyColumn    = 0;
int cipherColumn = 0;
int offset       = 1;
int nextWord     = 1;

Il problema è che quando si cambia un nome o si aggiunge una variabile, potrebbe essere necessario riformattare l'intero blocco per mantenere l'aspetto gradevole. Non è per il lavoro tanto quanto per i cambiamenti insignificanti che introduresti, sembrerebbe orribile in un sistema di controllo della versione. Il tuo collega ti vedrebbe modificato il file e fare una diff con la versione precedente per vedere cosa hai fatto. Quindi ogni linea si illuminerebbe come cambiata, oscurando il vero cambiamento. Dipenderebbe un po 'dalla qualità dello strumento di confronto utilizzato quanto questo sarebbe effettivamente negativo, ma in generale non è una buona idea rendere il codice troppo personale e / o far dipendere la formattazione di una riga dall'altra.

A volte delineare può servire a uno scopo, se hai decine di linee consecutive che sono quasi uguali, sarà facile individuare dove sono diverse se le delinei.

Nota che in un ambiente di lavoro potrebbe essere in corso una formattazione automatica che eliminerà qualsiasi formattazione elaborata che esegui nel tuo codice prima di inviarlo al sistema di controllo della versione.

Disclaimer: sto esagerando un po 'qui per chiarire il mio punto. Quindi prendi qualsiasi superlativo con un granello di sale.

Il tuo insegnante ha ragione al 100%: non esiste più una "regola d'oro" di circa 80 caratteri (a meno che tu non stia scrivendo codice linux). Quella regola è stata stabilita a causa delle dimensioni dei terminali in quel momento, ma al giorno d'oggi, puoi facilmente riempire oltre 150 caratteri nella finestra del tuo enditor. E anche se superi questo limite, il tuo editor spera di avvolgere delicatamente la linea in modo da non dover scorrere.E l'unica ragione per non andare oltre gli 80 caratteri era la necessità di scorrere .

Detto questo, c'è davvero la necessità di non lasciare che le tue linee crescano indefinitamente. Più lunga è la linea, più diventa difficile per un essere umano analizzare. Ma i nomi di variabili brevi non sono il rimedio al problema delle linee lunghe .

Il rimedio è dividere logicamente le tue espressioni introducendo variabili ancora più correttamente denominate . Non cercare di essere intelligente con gli spazi bianchi. Basta identificare qualsiasi sottoespressione che può essere appropriatamente nominata e creare una variabile per essa. Ciò semplifica sia il codice che calcola la variabile, sia il codice che utilizza quella variabile .

Non fa parte della tua domanda, ma vorrei commentarla comunque: è una pessima idea allineare verticalmente la tua = operatori.

Ci sono tre ragioni per questo:

1. La modifica di un blocco contenente operatori allineati verticalmente è una PITA. Ogni volta che cambia la lunghezza della variabile più grande (rinomina, aggiunta, cancellazione), è necessario ritoccare tutte le linee nel blocco per ripristinare il layout "bello".

   Naturalmente, questo problema può essere leggermente ridotto usando un editor competente, quindi è la ragione minore. Il vero motivo è il secondo:

2. Quei cambiamenti spuri negli spazi bianchi introdotti dal riallineamento non giocano bene con i moderni sistemi di controllo della versione come git. Tendono a creare quantità significative di conflitti di unione in cui non si è verificato alcun conflitto reale e in cui nessun conflitto verrebbe segnalato se l'allineamento non fosse utilizzato. Ognuno di questi conflitti spuri ti costerà tempo prezioso per niente .

3. L'allineamento porta zero significato semantico . È inutile. Non c'è nulla che tu possa capire meglio con l'allineamento. Ogni riga nel tuo blocco deve leggere da sola per capire cosa fa, la connessione con le righe sopra e sotto è di natura puramente sintattica.

Poiché l'allineamento non ha alcun significato semantico, ma produce costi significativi, è necessario disimparare l'abitudine prima che ti costi ancora.

Se ti piace così tanto il limite di 80 caratteri, prova a programmare fortran. È vero, i nuovi standard hanno elevato il limite di fortran a 132 caratteri, ma rimane in vigore come sempre paralizzante la compilazione di qualsiasi programma che superi il limite. Se sei un bravo a programmare, verrai presto ad odiare il fortran, incluso il suo limite di lunghezza della linea. Dopo di ciò, sarai guarito per il resto della tua vita.

Io stesso ho dovuto fare un po 'di programmazione fortran in modo professionale e vi dico che mi ha insegnato a odiare il limite di lunghezza della linea più caro. Non c'è assolutamente nulla di più frustrante che dover dividere una riga altrimenti semplice e leggibile in parti solo perché il compilatore non la compilerà più correttamente. E ci sono sicuramente righe di codice che sono molto semplici quando sono espresse come una singola riga.

Molte convenzioni stilistiche (non regole!) Sono sorte nel corso degli anni a causa delle limitazioni negli ambienti di programmazione. Ai tempi delle schede perforate, avevi un forte limite al numero di caratteri che potevano apparire su una linea di origine fisica (motivo per cui Fortran riservava la colonna 6 per i caratteri di continuazione della linea). Non è stato molti decenni fa che stavo lavorando su un terminale VT220 ambra su nero 80x24; mentre gli editor che ho usato non hanno limitato le righe a 80 caratteri, la vita è stata molto più semplice se hai fatto del tuo meglio per evitare lo scorrimento orizzontale.

Nelle versioni precedenti di Fortran (fino al '77, IINM), non potevi nemmeno avere identificatori che fossero lunghi più di 6-8 caratteri. Anche negli anni '80, C avrebbe garantito che i primi 8 caratteri con nomi esterni fossero significativi (motivo per cui alcune funzioni di libreria hanno nomi meravigliosamente descrittivi come strpbrk).

Naturalmente, tra due decenni nel 21 ° secolo, non abbiamo più quei limiti. Non c'è motivo di non utilizzare identificatori più descrittivi.

Il fatto è che, nei contesti giusti, ied je ksono perfettamente ragionevoli, nomi significativi . Se sto ripetendo un array o un vettore in un ciclo e ho solo bisogno di qualcosa per identificare l'elemento corrente, ifunziona perfettamente. Non userei un nome del genere currentElement: non è più significativo in quel contesto e aggiunge solo confusione visiva.

Detto questo, il tuo insegnante non ha torto nel costringerti a pensare in termini di nomi più lunghi e più descrittivi per tutto : la vita sarà più facile per te se prima prendi quell'abitudine e poi impari dove economizzare se necessario. Come qualcuno che è stato un tempo costretto a rientrare tutto in 8 caratteri o meno, è sicuramente meglio sbagliare sul lato della più informazioni rispetto a meno. Man mano che acquisisci più esperienza, imparerai dove puoi risparmiare sulla lunghezza dell'identificatore e dove devi essere un po 'più descrittivo.

Non sono sicuro che funzioni per c oppure no, ma esiste un modo per dividere le formule su più righe? So che esiste qualcosa del genere per Python.

Vedi se riesci a iniziare + (rowSize * nextWord) + nextWord]) {su una nuova riga. (Come premere invio nell'IDE e vedere se lo rientra in modo che C sappia che l'espressione precedente è stata completata sulla riga corrente)