Sometimes IDEs can be absolutely fantastic! For example, Eclipse works wonderfully with Java, and Visual Studio and C# go together like peanut butter and jelly. When IDEs work well, they tend to work fantastically.

On the other hand, sometimes you have to fight relentlessly just to get an IDE to cooperate. Other times, there just isn’t an appropriate IDE for the language you intend to use. IDEs can very easily hurt more than they help, especially if you’re only using it as a glorified text editor. The ability to work independent of an IDE is a very useful skill to have, and it turns out that it isn’t all that hard! Heck, you may find that you prefer it! If nothing else, it’s a great way to learn to be less dependent on your IDE of choice.

So, what software will you need?

Text Editors

The most obvious software to look into first is a good text editor. Though there’s a learning curve to them, I highly recommend learning guided tour online. Both editors work on many different platforms, and if you’re using Mac OSX or some flavor of Unix or Linux, the odds are decent that vim is already installed – just run it from a terminal!

Vim and Emacs are both highly customizable, and you can get a large number of “IDE features” in them: syntax highlighting, code completion, project views, jumping to different sections of your file (i.e. jump to X method), etc. It’s been my experience that syntax highlighting works more-or-less out of the box in both editors, but it’ll depend on your configuration. If it’s not set up, it’s easy enough to turn on (Google it!). As far as the other features go: a quick Google search will turn up plenty of similar advice for that editor.

If you’re truly against taking twenty minutes to learn the basics of an editor that you’ll be using for countless hours to program in, Notepad++ for Windows will work basically like your typical text editor, though it’s not as flexible as the above options.

A Compiler

(Disregard this section if you’re not using a compiled language in the first place, obviously)

Some IDEs (though not all) will handle all of the compilation details for you. Visual Studio, for example, comes with its own compiler(s) and even sets up build automation for new projects. Obviously, we’re going to need to get a compiler ourselves if we’re not using an IDE that provides one.

For a number of languages, the respects the user’s freedom.”

Of course, there are many other options out there. Your best bet is honestly doing a quick Google search and seeing different recommendations, comparing features to what’ll match your project best, etc. Heck, you can even compile from the command line using Microsoft’s compilers if you *do* have Visual Studio installed and just want to stick with that.

Build Automation Software

Once you’ve got a decent text editor in your hands, you’re probably going to want an easy way to automate your builds like many IDEs do. Typing the same commands over and over is tedious, and it’s very easy to forget a step or two in there. Thankfully, you have a few options.

GNU Make

Makefiles are a common way to automate builds. Re-building is as simple as running “make” in the project directory. Makefiles, the text files that guide the process, can be incredibly simple:

CApp:
 
  	g++ -o ./bin/Schmupp ./src/*.h ./src/*.cpp `sdl-config --libs` -static-libgcc

But, more importantly, they can also be very robust:

IDIR =../include
 
  CC=gcc
 
  CFLAGS=-I$(IDIR)
 
  
 
  ODIR=obj
 
  LDIR =../lib
 
  
 
  LIBS=-lm
 
  
 
  _DEPS = hellomake.h
 
  DEPS = $(patsubst %,$(IDIR)/%,$(_DEPS))
 
  
 
  _OBJ = hellomake.o hellofunc.o
 
  OBJ = $(patsubst %,$(ODIR)/%,$(_OBJ))
 
  
 
  $(ODIR)/%.o: %.c $(DEPS)
 
  	$(CC) -c -o $@ $< $(CFLAGS)
 
  
 
  hellomake: $(OBJ)
 
  	gcc -o $@ $^ $(CFLAGS) $(LIBS)
 
  
 
  .PHONY: clean
 
  
 
  clean:
 
  	rm -f $(ODIR)/*.o *~ core $(INCDIR)/*~

(Source: This tutorial)

Even if you were to sit down and read through all of make’s documentation, it’d only take a few hours. More realistically, to get started you can online, learn it in about fifteen minutes, and just do a Google search when you need to learn how to do something new.

You can download Make here, though a number of *nix variants will have it installed already.

Just run a script

Though this is not the most robust option, you can always just run a script with the appropriate compiler commands. On Windows, it’s as simple as making a .BAT file with whatever you’d normally type in the command line:

:: Compile.bat - Made because typing this command over and over gets old fast
 
  g++ -o ./bin/Schmupp ./src/*.h ./src/*.cpp `sdl-config --libs` -static-libgcc

The Linux equivalent would be making some sort of shell script, though that’s hardly my forte. I’d imagine it’s not much more complex.

Other Options

Given this isn’t really my forte, I’m going to defer this one to Wikipedia’s List of build automation software. There are a lot of options out there, and there’s no way I could possibly cover everything in one post.

Debugging

This is really, really going to come down to what language you’re using. Different languages will have different tools, and they almost all have high learning curves initially. Of course, most debuggers in IDEs have rough learning curves at first also, so, you know, not a whole lot of difference there. You might have to get used to a command line, though, which can intimidate some people.

GDB is a pretty robust piece of software that works for many different languages, including (but not limited to) Ada, C, C++, Objective-C, and Pascal. GDB is incredibly powerful, and I highly recommend it. I’ve actually been told (but haven’t verified) that Eclipse actually uses GDB for its debugger for a number of languages and just provides an interface to it, so learning to use it directly would hypothetically give you a bit more power and flexibility.

Beyond GDB, I’m unfortunately going to have to leave this one to you given there are countless languages and thus countless appropriate debuggers for them out there.

Source Control

Some IDEs handle source control for you, traditionally through plug-ins. In this case, I recommend either finding an alternative with an interface, or even learning the command-line interface to your source control of choice (it’s really not that bad!). For Windows, I’ve had great experiences using TortoiseHg for SVN, Git, and Mercurial respectively. That being said, I often work with the command-line interface anyway. Most command-line tools version control-wise are pretty straightforward to learn in my experience, though it’ll obviously have more of a learning curve than an interface.

Conclusion

If you have any questions, feel free to leave a comment or send me an email. Hopefully, though, this article covered everything you’ll need to get up and running!