Tools

Development environment: use Eclipse. Although some people are raving about latest NetBeans release. Eclipse has more plugins though. Ctrl+Shift+L is your friend -- you'll see a popup listing all keyboard shortcuts.

.NET or Java, you have to have continuous builds, unittests, functional tests, code-analysis scans, sane source control practices in additional to design and code reviews, not to mention proper. I am not trying to sound pompous – it just makes sense after you try it.

Start with good code analysis tools and there are a few descent alternatives to FxCop in Java world. The sooner you set up code checks that easier it’d be to keep it clean.

• PMD is a static analysis tool that examines the source code. I am not crazy about all the rules and lowered “final” keyword priority to 4 but bumped up Cyclomatic Complexity to P1. CPD is part of PMD package and will not let you get away with copy-paste code that so often leads to errors. I don’t recall seeing a warning in FxCop.
  
• Findbugs is another good tool that examines compiled code (so don’t run it next to Code Coverage tool, like Clover). I set it up to run it on release builds only.

Both PMD and Findbugs have Eclipse plugins but don’t be tempted to suppress warnings or your code will end up being cluttered with comments that make no sense when a new tool comes around. Just fix what you need to fix and lower priority for warnings or remove checks altogether for things that you don’t care for (e.g. “variable names are too long” nags from PMD…).

• Code Coverage - Clover.

Continuous builds is the key (we used Bamboo to run our Ant scripts). Continuous builds should run unittests. Unittests without code coverage report don’t count, so setup Clover.

It’s cheap, effective, and will keep you honest especially when you start failing the builds when code coverage is below certain limit (we pick 90% in our team).

Clover plugin is very useful as well; just make sure to place instrumented class files in the project output folder (see screenshot).

Another useful hint for clover is to automatically clover off if (log.isDebugEnabled) and similar statements -- setup a statementContext filter in the Ant script:

<target name="with.clover"> <clover-setup>
<statementContext name="iflog" regexp="if.?\(log\.is.*"/>
<statementContext name="iflog_debug" regexp="if.?\(isDebugEnabled\).*"/>
<statementContext name="iflog_trace" regexp="if.?\(isTraceEnabled\).*"/>
…
</clover-setup>
</target>

<target name="clover.reports">
<clover-report>
<current outfile="${clover.report.html.dir}" title="MyProject"> <format type="html" filter="iflog,iflog_debug,iflog_trace"/>
</current> </clover-report>
<clover-check target="90%" filter="iflog,iflog_debug,iflog_trace" haltOnFailure="true"/> </target>

Notice clover-check with haltOnFailure option in the segment above -- it'll keep you honest!
Another caveat when using clover: while it recognizes code as test when it that contain JUnit attributes, it tends to treat any helper classes that you may need in unittests as real code (even if they’re in the tests folder and you marked tests folder as such in clover-setup). Not a bid deal – just use ///CLOVER:OFF directive and your code coverage will be fixed.

• Code Reviews - Crucible

We are starting to use a fantastic code review tool and one day I'll document the best practices; meanwhile, check out http://www.atlassian.com/software/crucible/screencast.jsp