Lambda the Ultimate

There is a IEEE spec governing reuse throughout the whole software product lifecycle (including requirements), but I forget the IEEE standard #. It is so boring to read, though.

There are so many factors. What is the unit of code subject to quality criteria? We can imagine a code base comprising many units which have differing levels of quality. I'd say so, but even the presence of well defined and separate units itself can be difficult to discover and differ greatly depending upon the skills or culture of the development team.

Can we ever separate quality from the language processor and runtime? Even a "non-performance sensitive" piece of code will nearly always have implicit, approximate performance requirements. For example, say, nearly everyone would judge a "strlen" style routine that takes 14 hours to execute to be of "poor quality."

Need we implicitly bracket our code criteria by the source language's features and limitations, so that scoring "reuse" or other quality criteria for C, Pascal, Python, Scheme, ML and Scala must always be defined in a language dependent fashion? Or, conversely, can we deem a body of code to be of poor quality simply by misapplication of the "wrong" language to a particular problem domain?

Many, many moons ago, I performed several code reviews. One lesson burned into my brain from those days was: "Quality Criteria Compete." Even if, in fact, some quality criteria may end up being mutually reinforcing, it's still a very good working assumption to start with.

During code review engagements, my first step was to ask the team if quality criteria were well defined in writing in advance (they never were). Second, I presented the team with an extensive list of candidate code quality criteria that I forced them to rank in strict priority order. I never even looked at the code until after they completed this exercise.

This helped to frame the review by the project goals and project-local coding practices. In turn, this helps the reviewer avoid arbitrary imposition of their own priority criteria coding style preferences during evaluation. Say, in C++, I might like the extensive use of exceptions, smart pointers and multiple inheritance (I don't, actually), but it would be foolish for me to say that a use of C++ as just a "better C" in some project automatically disqualifies the code base as having "poor quality" because of divergences from my own preferences.

I relied quite a bit back then on a lengthy hardback book on code reviews, but have now forgotten its title and author. I might be able to dig it up over the next day or two. I found it a very thorough, perhaps too thorough for some projects, but still reasonably measured and pragmatic approach to the problem.

Scott