Is there a benefit to compiling your code as you go?

CaptainCodeman asks:

I recently had a job interview in which they gave me an hour to write some real code. It wasn’t a huge amount, probably less than 100 lines. After about 45 minutes, I compiled, ran it, and got it to work. I may have spent 5-10 minutes working out compile errors and a couple minor bugs, but overall it was very smooth. (Incidentally, I did get an offer from them.)

However, what puzzled me was that after I handed over the completed code, the interviewer told me that the only thing I did wrong was “not compiling as I go along”. I asked him what the difference is, and he said “what would you have done if you finished the code and it didn’t compile in time.”

In my understanding that’s an invalid argument, because “getting code to compile” for a given length of code generally involves fixing a constant number of compile errors and takes a fairly constant amount of time, which should be the same whether you do it after you finish writing the code, or if you interleave it with your coding time. If anything, interrupting your coding to search for missing semicolons would probably be detrimental to your efficiency. Except in extreme circumstances when I’m experimenting with obscurities around edge-cases on things like virtual functions in derived classes, etc. it seems reasonable to expect that code written by a an experienced developer will compile, minus the occasional typing error, and even if it doesn’t, it’s not as if I would have to rewrite a portion of the code in order to fix the compile error.

In another similar incident, I was given an incomplete codebase in an interview, and asked to finish it and make necessary modifications to get it running. I started by reading through the existing code, and then after a few minutes (even before I had finished looking at the code), the interviewer told me that’s enough. When I asked him what he would have done (i.e. “what did I do wrong”), he told me that he would have started by immediately getting the code to compile.

Why is that even relevant? In my opinion and in my experience, whether or not a piece of code compiles is essentially random, involving things like whether or not semicolons are missing, and has little to do with the correctness of the underlying program. (To me, focusing on compiling is like running an article through a spell-check without proofreading to check the grammar.)

If you give me a piece of incomplete code, the first thing I do will be to read it. I won’t even try to compile it until I know what the code is doing and I know the algorithm is correct.

Anyway, these have been just a couple recent incidents, but in general I’ve heard many developers talk about compiling their code as they go along, and yet nobody has been able to tell me the benefit of doing so. I understand the benefits of *testing* your code as you go along, but why compiling?

So my question is this: Is there something I missed? Is there actually a benefit to compiling as you go along? Or is this some sort of myth propagated by the software community that you must compile your code frequently.

See the full, original question and all answers here.

Quick fix

Oded♦ answers (188 votes):

Is there actually a benefit to compiling as you go along?

There is. It gives you a shorter feedback loop—which in general, when designing (UI, writing software, visual design etc.) is a good thing.

A short feedback loop means you can quickly fix errors early on, before they become more expensive to fix.

To borrow your example, say you were coding in a C-like language and forgot a ‘}’ somewhere in the middle of the program.

If you compile just after you finish writing the statement, you can be quite certain you have just introduced the compilation error and can fix it there and then, within seconds.

If you don’t, however, you would have to spend a good amount of time reading the code, looking for the exact position where the ‘}’ is and making sure, once you have located the error, that the fix is indeed what was intended. This would take place a while after you left that bit of code. It wouldn’t be as crystal clear as during the moment you wrote it.

Now, yes, the end result is the same, but you wasted a good amount of time on syntactical issues that the compiler is there to help you with—an amount of time that could be significantly shorter if you compiled as you went along.

Related: “Why are compilers so reliable?”

Part of the test

pjc50 answers (94 votes):

Compiling is a form of test, especially in languages which make extensive use of types such as Haskell or ML. In other languages it’s a syntactic scan that tells you little.

Having said that, “compile as you go” seems to me a very situational habit. You could equally be marked down for being “twitchy” for compiling more frequently than the interviewer’s personal prejudice. It sounds like nitpicking; nobody likes to admit that a candidate has aced the test. It tips the scales of the salary negotiation.

Not all build systems are fast. I worked on a (C++) project where Make would spend 30 seconds just stating everything to determine whether it needed to build or not, and most files would take a couple of minutes to build if you had made changes. We were reluctant to do this more frequently than every 10-15 minutes. Someone will no doubt supply an anecdote of when compiling involved taking your deck of punch cards and carrying them to a different building.