6.1. Inspection Testing

Other people are going to look at your code—they may find bugs—and they are very likely to comment on its readability and maintainability. If you picked a consistent style (see Perl of Wisdom #6) and consistently commented your code, they should have fewer nits to pick in that department.

You are not bound to accept every comment from the people reviewing your code (people who should be your peers; this process is not a management function), only the ones that make sense. The more you can keep your ego in check, the better, because you want to be able to learn from the process; merely showing off how brilliant your code is won't do anything to improve your craft.

A mammoth bone of contention that often arises is the issue of code clarity. If a neophyte programmer presents code to veterans, the latter will suggest all sorts of optimizations to abbreviate the code. This issue is more acute with Perl than perhaps with any other language ever invented. Even more vexingly, an expert programmer showing code to novices will hear all kinds of standard idioms attacked as “obfuscated,” “too clever,” or “incomprehensible.”

There is no universal solution to this problem. If the practice at your business is to code at the level of the lowest common denominator, then the presence of a beginner will drag the whole team down. If the practice is to code to the level of the majority then the value of an expert will be diminished by an average team. On the other hand, the expert's code will be useless to the company if no one who's left on the team can understand it after the expert leaves (although it might motivate some of them to improve their skills). Only a wise manager can decide what's right for their team. If you're managing a team that harbors a prima donna, try suggesting to that person that the greatest wizard of all is the one who can present an advanced idiom in a way that makes it understandable to novices.^[1]

^[1] If they pooh-pooh this suggestion, refer them to the writings of physicist Richard Feynmann, who is probably one of their heroes, and who firmly believed that any physical principle that was truly understood could be explained at the high school level.

The one tip we can offer is to use standard idioms and styles wherever possible. If you code something in a way that is familiar to other people, then even if they don't work at your business they can be hired, or other team members can learn the idiom as it is shared through books and the Internet. If a reviewer says you've coded something for which a well-known idiom exists, find out what that idiom is. The benefit in this respect of frequenting Internet newsgroups and mailing lists is huge.

If you're creating large systems in Perl, they should almost certainly be broken down along object-oriented lines. It will be much easier to understand each object class one at a time.

You might also consider the CPAN module B::Fathom. This generates a score representing a measure of complexity of the code it is fed.