Our development process is as follows
code the task -> someone else QAs code and documentation -> task is merged into trunk.
Recently a colleague is refusing to pass the code QA due to issues with indentation and whitespace.
Here are examples of these issues (syntax is SAS):
%if &syserr gt 0 %then %goto err; /*last line of code*/ /* Footer area*/
Extra line of white space, and not indented inside proc sort:
/* 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;
Extra white space between steps:
/*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;
The question is, being a good programmer, is looking over your code and correcting all this kind of thing the right thing to do, or is this just ridiculous?
There is an additional complication, that because we don't have continuous integration or automated testing, it's not possible for the QAer to quickly fix up these issues and commit the code, for risk of accidentally deleting semicolon or something. (To be fair, the risk applies to the initial developer making these changes, so either way if this mistake occurs, it just needs to be fixed and move on).