“Beware the IDEs of March” — Julius Caesar

My software engineering professor enjoys a joke at my expense when it comes to opinions about development. We frequently end up in informal discussions about Software Engineering practice and a subject that crops up a lot is whether or not to use an IDE (integrated Development Environment) such as Eclipse or Netbeans. Using an IDE does provide some merit, especially if it offers levels of collaboration, code management and updating that would be beneficial in a team scenario. However, the drawback I see from most IDEs is the amount of fluff I don’t need which insists on being there anyway. Sometimes I struggle to find my code behind all that UI.

Our conversation jumps back and forth between features such as code sense and inline documentation and he will make the case for refactoring tools ensuring that code is clean and he will readily admit that IDEs are fairly bulky but in the long run, text editors and command lines just don’t cut it for large projects. I don’t disagree (the aforementioned tools are very useful), but he has yet to convince me that a minimal environment cannot provide the features of an IDE. The other plus of a minimal environment is that resource use will be much lower- nothing will be running by default, it will respond to the programmers requests to do things.

My point is, while access to versioning systems, debugging, inline documentation, re-factoring and code sense are all very attractive features, I don’t need them all the time. IDEs rarely provide the ability to turn off those less frequently used features.

To make a case against IDEs I wish to propose a reasonably scalable command line based process (based on and extending the way I have been working on my own individual projects). In order to make an effective counter argument I need to address some of those ‘essential features’ of an IDE.

Pros for using an IDE (in no particular order):

1. Debugging
2. Source file navigation
3. compiles, links and runs at a keypress
4. auto-completion (codesense)
5. inline documentation
6. coding standards enforced
7. re-factoring facilities
8. trivial code generation (get/set)
9. Source control

In a series of posts I will outline (and refine) the way I work ensuring that I can effectively and elegantly satisfy the features given above. I intend to introduce the tools I use for editing code and testing and probably a few scripts to automate the tedious tasks. I work on OS X but expect this system will easily port to Linux or another UNIX based system running bash. I won’t explicitly guarantee success in using this on Windows but if you grab a copy of some UNIX command line tools I don’t see a serious problem.

Initially Expected Topics (which I’ll order according to complexity/work required to implement):

1. Setup and program execution
2. Source Editor
3. Debugger
4. Extracting Documentation
5. Source Control
6. Trivial Code Generation & Standards
7. Auto-Completion
8. Re-factoring