The Developer Ecology - Java: The Good Parts - page 181

IDEs
Nothing is as indicative of a generation gap amongst programmers than the use of IDEs
(which, depending on who you talk to, is an acronym for either interactive development en-
vironment or interactive debugging environment). [ 43 ] As a rule, older programmers tend to
stay with a separate editor, compile in a shell, and debug with a third tool. Younger program-
mers tend to have a single environment in which they do all three of these, and much more.
I was certainly a member of the older generation for a long time, and for good reason—the
commands of an editor become hardcoded into one's fingertips, and learning a different en-
vironment, even if it eventually offers more functionality, will cut down on your immediate
productivity.
But I now have trouble even imagining what it would be like to develop a system without the
aids offered by an IDE. In some sense, these environments are a simple combination of edit-
or, compiler, and debugger. But in fact they go well beyond those simple functions, supplying
lots of additional information along the way that used to require using multiple tools simul-
taneously and lots of context switching.
When I first started using an IDE, [ 44 ] I was using Eclipse, which still seems to be the most
popular of the open source tools. For the past couple of years, I've been using Netbeans. Al-
though comparing IDEs has become the equivalent of comparing editors in terms of the reli-
gious fervor of those who use them, I find at least these two are pretty much comparable (al-
though not, interestingly, always compatible). Each of these does some things slightly better
than the other, each has a model of work that is largely the same (until it isn't), and each has
a rather healthy group of contributors moving the tool forward. In what follows, I usually will
be talking about my experience with Netbeans.
IDEs now offer both code completion and online documentation as part of the editing process.
While entering your code, the IDE will (upon a configurable pause) show you which possible
set of methods or fields could be the completion of your partial typing, and allow you to pick
one of those completions rather than continuing typing. Pausing over a method call should
bring up the javadoc for that method. Typing in a method call will give you a template for the
arguments needed for the method. All the while, the IDE is parsing the code on the fly, allow-
ing you to see whether the code will compile properly while you edit. The IDE will even keep
track of your import statements, automatically importing the classes you need and flagging
imports that are not used. The IDE will also format your code, which is an easy way to ensure
that all members of a team use reasonably consistent formatting style.
IDEs also have facilities to aid in common refactoring processes. If you need to rename some
class, field, or method, the IDE can make the changes through an entire set of source files. If