A mistake that many junior developers make is to think that they’re writing code for the computer to understand, but computers don’t understand anything. They process. And computers can process some amazing messes without a hiccup. No, the entity that has to understand the code is the poor programmer (often yourself, weeks or months later) who has to maintain the code.

One of the very easiest things that a programmer can do to help make his code more readable and easier to understand is to adhere to some standard best practices and a rigid format. But let’s be honest…. that’s really hard to do when you’re in a hurry (and we’re always in a hurry). Eclipse offers limited support for formatting, but it doesn’t go far enough. That’s where a couple of my favorite tools come in: Checkstyle and PMD. These tools will force you into submission and remind you to correct your bad habits. So, what are they, and how do they work?

PMD (slogan: Don’t shoot the messenger) and Checkstyle are two fantastic customizable tools that both offer Eclipse plugins to help out a developer who might otherwise, um, forget to keep things in check. Some definitions are in order. PMD is a tool that checks your code for possible bugs, overcomplicated methods, duplicate code - that kind of thing. Why it’s called PMD remains a bit of a mystery. Checkstyle makes sure that your code adheres to a particular format, via means of a configuration file.

I have to be honest here. The first time I was introduced to these plugins I wanted to throw them out within 10 minutes. I absolutely loathed them. How dare it tell me that my method was “too complex”? How annoying to be reminded to enter a space after that bracket! But over time I came to appreciate the consistency of my code. It was nice to have that not-so-subtle reminder that I ought to consider refactoring to make my method a bit cleaner, a bit shorter.

Having used these tools now for several months, I really miss them when using an IDE that doesn’t have them installed. I highly recommend them to every Java developer. They need a little customizing so that they enforce the rules you or your organization care about, but the payoff of having nice, clean, professional-looking code is well worth the initial pain of having a tool force you to squash all your bad habits. So install them, try them out. You’ll thank yourself when a few weeks later you have to understand what you wrote.

An often-overlooked feature in Eclipse 3.2 is support for Change Sets in the Team functionality. What are Change Sets, you ask? Well, picture this oft-occurring developer scenario:You’re in the middle of working on an import feature (aren’t they all?), let’s call it FeatureX, happily coding away and hoping to be awarded FeatureImplementorOfTheYear, when suddenly an “emergency issue” is dropped into your lap. You have to drop everything you’re working on and attack this Feature Y. But here’s the problem: you’ve modified 20 source files already, and they’re not ready to check in! Implementing this “Emergency issue” is going to require modifying another dozen or so files and when it comes time to commit your FeatureY, how do you remember which files were modified for which feature?

Here you have a few possibilities:

• Checkout a new copy of your branch from CVS/SVN and implement FeatureY on that local copy (not very efficient).
• Write down or otherwise commit to memory every file you changed for FeatureX and every file for Feature Y, then make sure you only commit the right ones when it’s time to do so. (good luck!)
• Use Eclipse’s “Change Set” functionality to “tag” the files for FeatureX and don’t worry about them - Eclipse will remember them for you!

Here’s how it works:

1. Before you start work on Feature Y, perform a Synchronize on your Project(s). Select “outgoing mode” and click the little button on the the right of the Synchronize toolbar to enable Change Sets (it’s greyed out if you’re in “incoming/outgoing mode”, and don’t even think about using it for “incoming” mode because it will take forever).
2. Select the files that were modified for FeatureX, then right-click them and select “Add to… New Change Set”. In the dialog box that pops up, give the change set a name (say, FeatureX), and if you like, give it a CVS commit message, then press OK.
3. Notice that Ecliipse has now segregated your Synchronize view to show files that are part of your new Change Set independently of the Project’s other changes (if any).

Now you can merrily go about working on Feature Y, content in the knowledge that next time you do a Synchronize, as long as your implementation of FeatureY didn’t modify the same files as FeatureX then Eclipse will keep track of which changes belong to which feature.

Change sets aren’t perfect, and they’re not the right tool in all cases, but sometimes they’re just what a time-crunched developer needs.