How many errors do you fix per compilation.

Question

I notice that I tend to fix one error, then recompile, then fix another one. SOmetimes if there are problems with many files I might fix one per file. How about you?

Answer 1

I normally don't have errors when I compile; I compile because I want to run the code. My IDE tells me about errors/warnings in a little status bar on the right hand side. Compiling to check syntax seems so last milennium.

Answer 2

I usually try to fix everything I can identify (ideally all), although, admittedly, sometimes it is a bit hard to keep track of it all.

It is not too hard to get to projects that just takes too long to compile, and doing so just to find which errors I hadn't fixed yet is just too wasteful and would drive me mad.

Answer 3

If my compilation is sufficiently quick (and, let's face it--it sucks when it isn't), as little as one, sometimes a few more. The problem is that errors tend to cascade, so one error can lead to 100 other false positives.

If I can tell that a problem I fix is going to be a problem elsewhere I'll often fix it at the same time. Likewise if I see a message of something that clearly isn't a false positive I will probably fix that too.

Answer 4

I usually only get multiple compilation errors when I've done something like adding a parameter to a method, leading to all callers failing to compile. At that point I just go through each of them in turn to fix them, possibly recompiling after I've finished each particular file (so if files X, Y and Z have three errors each, I'll fix the three in X, compile, fix the three in Y, etc). It's not a particular "rule" though and it doesn't really matter so long as you've got a sufficiently fast compilation cycle.

Answer 5

Usually I don't find any error during compilation time-- any such errors are highlighted by Resharper in IDE without me commiting the compilation at all.

Answer 6

When I work with compiled languages it's often small projects and compilation is very fast. I think I sometimes compile after each keystroke. =)

Anyway, for me the issue is if my tests run. Then my pace often is "write a test, implement it, make it work" (repeat). But I'm starting to enter the field of BDD and then my pace is somewhat less fine grained.

Answer 7

As previously mentioned, compiling to check syntax errors isn't as common now with modern IDEs. It's not so much syntax errors now, it's the logic errors you have to worry about that your compiler won't pick up (unwanted endless loops, if (x = 1), etc...).

Answer 8

Quite often one error can lead to several others further down so I tend to look at the errors and then choose my approach.

Of course the other variable is how long it takes to do a compile. I've worked on systems where it took 12 hours to do a total build, but thankfully those days are over. (-:

I guess nowadays I tend to take a "fix the first one then recompile approach" especially when I'm working on something where I can either perform the compile or run the script within vim. I map a key, usually v, to write out the latest copy of the file I'm working on and then either compile or run the script. Something like:

:map v :w<CR>:!%<CR>

when I want short code and test cycles.

HTH

cheers,

Rob