Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

For the longest time I've just done small app development. Building and debugging took a matter of seconds (or should I say - second?). I got fairly used to just debugging to test literally everything (and it's nice to see my stuff working - like a programming high almost). The problem is that as of late I've been working on a much larger project. The single solution contains 4 (and probably more soon) projects each very large. As it expands, compile times naturally increase making debugging a real pain. I'm stuck in my "compile every update" mode and it has wasted quite a bit of my time. Every visible update I want to see it.

So...

How can I get out of this irrational compile/debug habit and how often should I actually be compiling and debugging my application?

EDIT:

I'm utilizing Visual Studio. My compile times I realize are minuscule to what most of you are used to I realize, but it is still wasting my time :)

share|improve this question
6  
what tools and framework are you using? –  Yusubov Jul 27 '12 at 1:52
1  
@ElYusubov There, I've made an edit to my question. –  Xan Jul 27 '12 at 11:36
1  
@Dlamk: I once used Visual Studio, and still use it once in a while now. It's a great IDE, but the first thing I would recommend is that you should stay away on its debugging feature. Most of the time it's overkill and way too slow. Do de-bug by logging instead (log4net recommended) –  Hoàng Long Jul 28 '12 at 12:16

8 Answers 8

up vote 6 down vote accepted

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.

share|improve this answer
    
This seems to be the only answer that offers a counter-argument to "compile / test often". While I normally do everything I can to get compile times as low as possible, sometimes your environment just doesn't allow it to be quick enough. In these cases, it definitely IS possible to code hundreds of lines of code without a single mistake, especially if you're practiced in the area. A good example is Knuth's programming entry win with a single compile, although that is definitely not a realistic expectation. –  Daniel B Jul 27 '12 at 6:16

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.

share|improve this answer
2  
+1 for recommending a good logging mechanism. It is indeed invalueable if an angry customer calls... –  Radu Murzea Jul 27 '12 at 6:33

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.

share|improve this answer
3  
This has nothing to do with compiling... –  Thomas Eding Jul 27 '12 at 0:29
    
This answer may not specifically deal with compiling. Working of the question though the problem appeared to be that compile times got to high to be able to test small changes in functionality by debugging. Automated testing would be able to help solve this issue. Well written unit tests would be able to provide that feed back and help to regularly hit the high and break the "Irattional compile/debug habit" –  Klee Jul 27 '12 at 1:31
1  
I don't know, therefore unit tests. –  Jordan Jul 27 '12 at 4:31

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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!

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.