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).