Slashdot Mirror
Replacing Humans with Software Inspectors
An anonymous reader writes "What if you were able to perform a portion of your code reviews automatically? In this first article of the new series 'Automation for the People', development automation expert Paul Duvall begins with a look at automated inspectors like CheckStyle, JavaNCSS, and CPD. The piece examines how these tools enhance the development process and when you should use them." From the article: "Every time a team member commits modifications to a version control repository, the code has changed. But how did it change? Was the modified code the victim of a copy-and-paste job? Did the complexity increase? The only way to know is to run a software inspector at every check-in. Moreover, receiving feedback on each of the risks discussed thus far on a continuous basis is one sure-fire way to keep a code base's health in check automatically!"
If you've got a reasonably recent JVM installed you can run CPD via Java Web Start here.
There are some examples of CPD output there too - like the duplicate code chunks that it found in the JDK source code and in the Apache httpd source code.
For much more on CPD, see chapter 5!
The Army reading list
I would say that, like any other code generator, wizard, druid, whatever you want to call it, this has a great potential to help with programming. As long as developers using it don't get lazy about checking their own code.
As a tool to point out obvious code flaws, catch conflicting code in large projects, etc. this is great. But I've found over the years that if you don't understand how to do something manually and aren't able to second guess a tool when it makes a mistake then these types of things can end up being more trouble then they're worth.
Just my $.02
Creationist Textbook Stickers Declared Unconstitutional by CowboyNeal
These tools are very limited in their scope - FindBugs is a very useful and powerful tool for locating bugs or potential bugs in Java code, and I've used it to find some potentially serious bugs in large, relatively mature pieces of code before now. Using it to help find potential failures in newly modified pieces of code seems like a good idea.
++ Say to Elrond "Hello.".
Elrond says "No.". Elrond gives you some lunch.
The only way to know is to run a software inspector at every check-in.
Or you can hire people who are good and who you trust. A real human will do a better job of 'code reviewing' every time, and if you hire good people, then you don't need to worry about what they commit. An occasional check should be enough to make sure you haven't accidentally hired a loser. (Also human code reviews, if done correctly, are great because they help everyone become better programmers).
This is easy to do in small companies, but somewhat harder in big companies. Still, if I were CEO, and my managers started using this tool, I would get worried and start thinking seriously about how to change the company culture. You don't want your company to become like Qualcomm, or Novell, where bureaucracy rules the day.
Qxe4
If only we could run CPD (copy/paste detector) on /.
I bet the numbers would be off the charts!
The thing to remember about automated code inspectors is: be smart about it.
// Iterate over all files /* nothing to do here */) // Get the next file // If the file has a modification date later than now // Throw an exception stating that the file is modified in the future
Don't trust the code inspector to enforce a policy (except maybe coding style).
There's a lot of boilerplate code that goes into a program, and a code duplication monitor will cause all sorts of headaches in this area.
The same problem exists with comment checkers. If code is written properly, there is usually very little need to comment inside most methods. The name and javadoc will give more than enough description of what the method will do (you DO use javadoc, don't you?)
It's only as the method's complexity increases to a point where it's not blatantly obvious what's going on inside that you need comments at that level.
I've had too many managers force me to comment like this:
for(Iterator iter = files.iterator(); iter.hasNext();
{
File file = (File)iter.next();
if(file.lastModified() > new Date().getTime())
{
throw new ModifiedInFutureException(file.toString() " + has a modification date in the future");
}
}
Ok it looks much uglier after running through Slashdot's dumb filter, but you get the idea.
The above code in reality needs no comments whatsoever, except perhaps a single line at the top saying "Disallow modification dates in the future", but a bad policy caused ALL code checked in to comply with silly regulations, resulting in countless hours lost.
In truth, the date check code itself should have been implemented as a policy class to be added to the verify method, but I digress.