How can I get out of this irrational compile/debug habit

Practice. What has helped me is by solidifying my program design skills. Needing to ‘make sure it works’ is a sign that you’re lacking confidence in what you’ve done. You get confidence via practice of course, but also by using things you know will work. Taking known patterns (not necessarily design patterns, but they count) and adapting them to the situation at hand. Since you’ve done them many times before, you know them well enough to do them right and be confident that you’ve done them right.

how often should I actually be compiling

Personally, I don’t recommend compiling until you’re ready to run your tests. There’s too many coding environments that have sucky compilation either due to the language you’re using (I’m looking at you C++), the platform you’re working with, or the size/complexity of the codebase. It’s good to be able to work without that step and focus on the partial compilation/error checking that most modern IDEs provide while you’re working.

But it’s only a recommendation. Do what is most productive for you.

and debugging my application

When your tests fail, or a bug has been reported that has eluded your tests (and you can’t spot the bug without entering the debugger). This should be very uncommon when developing new code, and is a bad sign if needed when adding on to existing code.

Again, I tend to avoid the debugger these days for similar reasons that I avoid the compiler. Plus, once much of the code is known patterns spotting bugs becomes speedier since you’re familiar where things can go wrong.

This too is merely a recommendation. It’s nice to be able to spot bugs by eyeballing code, but the end goal is to produce quality software. If the debugger gets you that goal faster and more reliably, go right ahead and debug frequently.

In short, there are 3 things that I did to enhance the productivity when I’m in your situation:

• Good logging instead of debugging
• Unit test

• Daily build

  1. I strongly recommend logging against debugging using IDE. By a good log file, you will have a much quicker access to “what has happened” and the flow of the error, without re-compiling. Moreover, logging will also help you in troubleshooting the application when it is used by the clients, while debugging doesn’t.

  2. Many people here seems to recommend Unit test, but be aware that it will take time to learn and apply. Bad unit tests won’t help you. You may want to try start small, and adding them for the most important and error-prone feature of your application first.

  3. A daily build and some integration tests for important business work flow is another thing that saves my life so many times. Setting up an automatically build-and-deploy isn’t hard, but it will help you and your co-workers to make sure that no one breaks anything by accident before the acceptance test.

I also recommend you taking a look at the Joel Test. It’s very helpful for those who seeks to improve 🙂

UPDATE: More about logging. Just put a println statement here and there in your code may work, but you will want a full-fledge logging library if you are serious about troubleshooting in future. Every programming languages/frameworks now has a solid framework for logging, so you can count on that.

Unit testing is the answer. Good framework will allow you to execute only the tests that you’re interested in at the moment. And unit tests are small by definition so will compile and run fast.

First, you should use a very good ide with tools to help you to “pre-verify” your code logic. Something like eclipse or delphi or nusphere, depending of your language.

Second, you have to split your work on job codes. After a job is done, you compile only the files that were updated and them link to the rest.

Compile well and often. I typically do it after each block of new functionality has been completed. It’s not unusual for this to happen tens of times per day.

However, your IDE should really only recompile those files that need it. You don’t say what language you’re using but if you update header files any source files that include it will need to be recompiled. A complete recompile each time could be a symptom of poorly organised code.

If you’re using a strongly-typed compiled language, you really should be compiling very often, since it provides a first-pass sanity check that you didn’t write any invalid code. The longer you take between creating the error and detecting it, the less fresh it will be in your mind. If your project takes a long time to build, run an incremental compile instead. (If you can’t do that, use an IDE that supports it.)

And if your incremental compiles take too long, what are you coding in? On Delphi I can full-build our (enormous, ~4M lines) client app in about 2 minutes on a hard drive and a VM, or ~15 seconds on an SSD and no VM. Incremental compiles are even faster. If productivity is important, it could be a matter of “the right tool for the right job.” (Which is not to say that you should abandon your entire existing codebase and rewrite the whole thing in Delphi just because it compiles faster. That would be silly. But you ought to keep in mind that not everything builds equally slowly.)

As for running to test and debug, you should do that fairly often too. Not necessarily as often as you test-build, but every time you complete a feature or sub-feature you should give it a quick test or two right away, even if it’s going to be later tested in other ways or by other people. Remember, the longer you go between writing the code and detecting the error, the harder it’ll be for you to fix.

I generally have things setup to compile every time I save a file. Of course for that to work you need a build tool that will only recompile the files that need to be compiled. I generally use GNU Make for this. Actually I have my editor setup to compile the file and spot syntax errors with Emacs flymake mode so it probably does a compile every few seconds.

The trick here is that you are not rebuilding your entire project each time you compile you are only building the one component that has changed.

I will build everything from scratch once every few hours, generally if I am switching to a new branch or the like.

Are you working on Dotnet? If yes then following can be of use to you.

1. In various Projects added, there will be some/many references, make sure you make all the references to have the property Copy Local as FALSE
2. If you are developing ASP.NET stuff, make all the Aspx pages’ code behind files as Code files to avoid Build and even Saving them can do the job + the application need not restarted over and over again. (But make sure, before sending deployment, i.e. before final you make them CodeBehind again, as Precompiled code works the best at any time)
3. Go to a specific project and Build that only (right-click->Build Project) rather than building or Rebuilding the complete solution. This will save a lot of time.

Hope this Helps!