Automated Code Inspection

Closely related (but not identical) to SoftwareMetrics such as the CyclomaticComplexityMetric. Metrics are supposed to give an overall feel for quality, code inspection usually identifies specific potential problems. JTest is an example of a tool designed to automate code inspection (http://www.parasoft.com/products/jtest/).

Take a look at your CodingStandards. If they are not testable (in the sense of being automatable), would they otherwise qualify as requirements for your project? It is a good idea when writing CodingStandards to think about how you would test for compliance. When you get around to it, it will be easier to identify potential problem spots in the code automatically, and concentrate your manual review there.

Be careful with this one. The important thing in a code inspection is readability and design quality, neither of which an automated tool can detect. A tool may point out issues, but its focus is on superficialities. --JimLittle

I agree. Metrics are intended to give you some idea of design quality, automated code inspection some idea of the readability, and the use of 'dangerous' constructs. Neither is a substitute for thorough manual inspection of code. However, automated tools can detect common code smells and tell you where it smelled them, speeding the process of code review. This is all they can do (at present). Robert C. Martin's dependencies metric (http://www.objectmentor.com - site appears to be down, anyone got a better link?) is an example of one which explicitly attempts to look at 'quality' rather than 'quantity' (eg LOC metrics).

Other kinds of tool which speed manual code inspection - not covered here because they don't do any automated code inspection themselves - are flow analysis tools (like cflow, and profilers) and code outliners/class browsers; these give reviewers an overview of the static and dynamic code structure.

ThreadMode discussion....

The important thing in a code inspection is readability and design quality, neither of which an automated tool can detect.

Jim, I'm going to be controversial and argue this point (even though I agree with you above. I just think the sentence might need 'yet' at the end.) What exactly is it we look for in readable code? I think there is a difference here between coding 'standards' and coding 'style'. (this is going to be one of those arguments where I define the words to mean what I say they mean...) 'Standards' are the bits we can test. 'Style' is the bit where you say 'the code smells nice/nasty', but can't be more specific. I would contend that we can move large parts of the 'style' parts into 'standards'.

For example, take variable/method/class naming. Usually we require that the names are meaningful, as part of making code readable. However, by this we mean that (a) they mean something as words/phrases and (b) that this word/phrase is meaningful in context. (a) could quite easily be enforced by tools. Its just a spelling checker - you would split up wordsLikeThis or words_like_this and spell check the words individually; identifiers can be added to the dictionary so you can allow eg 'i' 'j' 'k' if you really want to, and so on. (b) is probably not automatable. Yet. But having enforced (a), we are well on the way to (b), and have at least detected and got rid of mostrosities like 'gshaj13()'.

The point is that you shouldnt give up on partial automation because the whole job is impossible. Automation is cheap, and can provide assistance all the time to a programmer (code reviews are at most once a day, even in XP). ArgoUml already comments on some aspects of your design. There may yet come a day when the dread paperclip pops up and says 'you appear to be writing a payroll system, would you like me to help', or we get green underlines under this.Violates().theLaw().ofDemeter();. -- BrianEwins

See also RefactoringNose and the code inspection functionality in IntelliJ.

CategoryAutomated