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?

[Read the full story]

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?

[Read the full story]