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
...welcome my new automated, software-inspecting overlords.
playmoney.me - The free alternative to paper board game play money
"Go away or I will replace you with a very small shell script."
If only we could run CPD (copy/paste detector) on /.
I bet the numbers would be off the charts!
We've experienced those brief and tempestuous infatuations with flowcharts, Warnier-Ott diagrams, top-down programming, structured programming, Jackson structured programming, source code control, the waterfall model, Royce's Final Model, the spiral model, the sashimi model, object-oriented programming, CASE tools, Rational Unified Process, SEI's Capability Maturity Model for Software, SEI's CMMI, feature points, function points, agile methodologies, and Extreme Programming, and... well... they were just trips to the moon on gossamer wings.
But this. This is different. Totally different. It's the real thing this time.
"How to Do Nothing," kids activities, back in print!
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.
Slashdot's title of 'replacing humans' aside, this article is right on. We do peer reviews of our code, but before we do, we make sure it meets our checkstyle conventions, and fix at least some of the egregious things that PMD, Findbugs, and a couple of the other reports we can get out of our Maven build system without any real effort.
This makes our reviews more productive, because people don't get caught up in discussions over curly brances, finding copied code, issues with contructor and exception idioms, etc.
The slashdot crowd is going to envison pointy-haired bosses basing performance reviews on this kind of stuff, which is a legitimae fear and shouldn't happen. Used in the hands of real software engineers though, this is similar in spirit to the woodworker's adage "measure twice, cut once". Loosely applied, "You know what you are doing, but be your own safety net".
-db
http://packages.debian.org/stable/admin/vrms
Virtual Richard M. Stallman
The vrms program will analyze the set of currently-installed packages on a Debian GNU/Linux system, and report all of the packages from the non-free tree which are currently installed.
Future versions of vrms will include an option to also display text from the public writings of RMS and others that explain why use of each of the installed non-free packages might cause moral issues for some in the Free Software community. This functionality is not yet included.