Quanto dovresti essere severo riguardo all'indentazione / spazio bianco? [chiuso]

8

Il nostro processo di sviluppo è il seguente

codifica l'attività - > qualcun altro codice e documentazione QA - > l'attività viene unita nel trunk.

Recentemente un collega si rifiuta di passare il codice QA a causa di problemi con indentazione e spazi bianchi.

Ecco alcuni esempi di questi problemi (la sintassi è SAS):

Spazio vuoto aggiuntivo:

        %if &syserr gt 0 %then %goto err; /*last line of code*/




/* Footer area*/

Linea extra di spazio bianco, e non rientrata nell'ordinamento proc:

 /* End Of header * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */


    proc sort data = %dataset ;
    by id; 
    run;
    %if &syserr gt 0 %then %goto err; 

    proc sort data = &second_dataset.;
    by id;
    run; 
    %if &syserr gt 0 %then %goto err; 

Spazio bianco extra tra i passaggi:

        /*join all details on for each record*/
        proc sort data = &data out = data_srt ; 
              by &conditions; 
        run;
        %if &syserr gt 0 %then %goto err;

        proc sort data = &data2.;
              by &conditions.;
        run; 
        %if &syserr gt 0 %then %goto err; 




        /*cartesian join*/
        data new_data;
              join data 
                          &data2.  ;
              by &conditions; 

        run;

La domanda è, essendo un buon programmatore, è guardare oltre il tuo codice e correggere tutto questo genere di cose la cosa giusta da fare, o è solo ridicolo?

C'è un'ulteriore complicazione, perché non disponendo dell'integrazione continua o dei test automatici, QAer non è in grado di risolvere rapidamente questi problemi e di eseguire il commit del codice, rischiando di eliminare accidentalmente il punto e virgola o qualcosa del genere. (Per essere onesti, il rischio si applica allo sviluppatore iniziale che apporta questi cambiamenti, quindi in entrambi i casi, se si verifica questo errore, deve solo essere corretto e andare avanti).

    
posta dwjohnston 26.11.2013 - 05:32
fonte

4 risposte

16

Sì, questa è la risposta giusta. Lo stile di indentazione dovrebbe essere coerente per tutto il codice.

Una grande parte del valore di una rientranza consistente è che è coerente. In questo modo le persone imparano a leggerlo facilmente, il che accelera tutti.

La mia regola generale è che qualsiasi stile di indentazione che la squadra vuole è buono, purché possa essere applicato meccanicamente. Applicarlo meccanicamente significa che non devi imparare i dettagli dello standard, o sprecare tempo a twidare spazi bianchi.

Anche la formattazione meccanica diventa un altro modo in cui gli errori risaltano. Se pensi di aver racchiuso il codice in un blocco, lo strumento di formattazione annullerà il rientro e sarà ovvio che hai incasinato. Ciò facilita anche il refactoring - a un livello elementare quando estrai un blocco di codice in una funzione, la formattazione automatica rimuoverà il rientro extra.

Autoformat significa anche che se davvero, davvero non puoi vivere con lo standard chiunque altro usa puoi formattare il codice nel modo che preferisci, quindi riformattarlo nuovamente prima di controllarlo. Poiché hai un passaggio di revisione, Ovviamente lo farò prima della revisione e se non lo facessi verrebbe raccolto allora.

Il rientro GNU è uno strumento che può essere fatto per eseguire automaticamente la formattazione di quasi tutto. Ho fatto una rapida ricerca e sembrano esserci strumenti per codice SAS per il formato automatico ma gli strumenti SAS non lo fanno per te.

    
risposta data 26.11.2013 - 05:55
fonte
5

Questa è assolutamente la cosa giusta da fare. Una delle parti più importanti della qualità del codice è la sua leggibilità. Se non hai indentato correttamente il tuo codice e disponi di spazi vuoti casuali ovunque, si riduce la leggibilità del codice.

Generalmente, il tuo team di sviluppo dovrebbe seguire tutti gli stessi standard di qualità del codice quando si tratta di rientri e spazi bianchi. Se altri moduli nella tua base di codice non inseriscono spazi bianchi aggiuntivi tra i passaggi, questo non dovrebbe neanche (a meno che, ovviamente, non migliori la leggibilità).

Non sono un programmatore SAS, ma se sto rivedendo il codice e il rientro è tutto fuori gioco e non sembra in ordine, certamente commento su di esso per il follow-up e, se davvero pessimo, fallisce la recensione .

    
risposta data 26.11.2013 - 05:48
fonte
3

Come dice lo zio Bob nel suo libro , la formattazione (anche gli spazi bianchi) è incredibilmente importante. Il software tende a essere letto molto più spesso di quanto scritto, quindi è necessario renderlo pulito e facile da leggere. È un metodo di comunicazione.

Idealmente, quando lavori in una squadra, stabilisci uno standard e tutti lo seguono. Idealmente, invece di snellire lo standard nelle singole revisioni di codice, crea uno strumento che farà il lavoro per te. (Non sai quale strumento potrebbe funzionare per il tuo caso, qualcosa come checkstyle per Java o StyleCop per C #).

Quindi vorrei chattare con il tuo collega e vedere se non riesci a trovare alcune linee guida su whitespace. Prendersi un paio di minuti per ripulire il tuo codice è valsa la pena se rende le cose coerenti lungo la linea.

    
risposta data 26.11.2013 - 05:54
fonte
2

Dopo un'esperienza di molti anni fa, leggendo alcuni codici F-16C / D in cui il rientro era rotto, devo dire che ottenere il rientro corretto è di fondamentale importanza.

È così importante che non dovrebbe essere fatto a mano e non dovrebbe essere fissato a mano. Ecco a cosa servono i computer.

Crea programmi per computer in grado di riformattare automaticamente il codice sorgente in modo che corrisponda allo stile preferito della tua azienda. Aggancia uno di essi al tuo sistema di controllo del codice sorgente, in modo che il codice venga automaticamente reso conforme quando viene archiviato.

    
risposta data 26.11.2013 - 07:42
fonte

Leggi altre domande sui tag