Software development and teaching it requires something more than a one pair of eyes to watch the code.

Essentially, the software development process is the process of translation from customer’s ideas down to code done collectively. That’s why code should be written more for reading by other people than for computer execution.

Unfortunatelly, our teaching system and existing developers rarely seem to understand this simple idea. At least, not until they will try to read and get some oldish perl code like this:

sub makesmblock { my($isblock2,@mh)=@_; my ($smi,$xmnum);  $xmnum=1;
foreach $xbit(@mh) { ($bit,$fpnum)=split(/\і/,trim($xbit)); if($bit) {
#print "$bit

"; if(($fpnum==1 && !($nocf)) || ($fpnum==1 && ($PROCESS{'domode'} || $PROCESS{try})&& !($ori_ha{'notrycontactform'}))){$bit.=qq~\|$transm41\|$my_http\?cf=3$ltag$vtag~; } if(($fpnum==1 && $sitemap==2 && !($nosm)) || ($fpnum==1 && ($PROCESS{’domode’} || $PROCESS{try})&& !($ori_ha{’notrysitemap’}))){$bit.=qq~\|$transm39\|$my_http\?sm=3$ltag$vtag~; }

(real code from real product)

Systematic code review is possible either by

  • scheduled real-life code reviews
  • pair development
  • distributed code review

Scheduled meetings with the only purpose of code review is a no-no in our software development team. As well, as in any team that doesn’t sit in a single office, I guess. Pair development is equally hard for geographically distributed team. Thus, we are left with only one option of distributed code review.

We are using trac for our project management for years with great success. That’s why I, naturally, tried to use trac peer review plugin.

No way

Given latest stable trac 0.10.3 you get html parse errors (#1035) due to crappy html, generated by plugin.

And even after you mask those errors with patch, you discover another defect (#938) that makes impossible to use this plugin at all.

Looks like its time to look for an external code review system. At least until someone fixes (rewrites) PeerReviewPlugin or writes another one.