As a follow up to my prev question:

What is the best aproach for coding in a slow compilation environment

To recap: I am stuck with a large software system with which a TDD ideology of "test often" does not work. And to make it even worse the features like pre-compiled headers/multi-threaded compilation/incremental linking, etc is not available to me - hence I think that the best way out would be to add the extensive logging into the system and to start "coding in large chunks", which I understand as code for a two-three hours first (as opposed to 15-20 mins in TDD) - thoroughly eyeball the code for a 15 minutes and only after all that do the compilation and run the tests.

As I have been doing TDD for a quite a while, my code eyeballing / code verification skills got rusty (you don't really need this that much if you can quickly verify what you've done in 5 seconds by running a test or two) - so I am after a recommendations on how to learn these source code verification/error spotting skills again.

I know I was able to do that easily some 5-10 years ago when I din't have much support from the compiler/unit testing tools I had until recently, thus there should be a way to get back to the basics.

  • 6
    I'm at a loss for what the actual question is here.
    – Tyanna
    Feb 25 '11 at 14:12
  • Let me clarify it by example. Let say I need to add a (not so) simple functionality into already existing application. Well, after I have figured out how to do so, I coded it, checked it quickly by skimming through a new code and changes I had to make to plumb the new feature in. Complied, started the application, did the manual testing - and it failed. Now I have to go back to debugger to see where it break, change the code again, test it again, and if it still does not work, I have to debug it again, etc... Obviously - the application stopped working because of the change I have made ....
    – user18404
    Feb 25 '11 at 15:57
  • ... so I can undo the change and see the application working again. My question is how to become more efficient in spotting such bugs in advance... Granted the bugs are frequently introduced because the original code is error prone, non-intuitive and convoluted - but ... anyway - how to get myself into effective code checking habit I have lost because with the great TDD tools code checking is not really important (if it compiles - it is testable and if it is testable - it will be tested in a seconds)...
    – user18404
    Feb 25 '11 at 16:02
  • so why not do it as you did it 10-15 years ago?
    – jwenting
    Aug 18 '14 at 9:53
  • Try to split large source files (compilation units) into smaller ones (e.g. avoid source files larger than half a dozen thousands lines). Work carefully on your build process. Certainly, latest features (e.g. Scheme scriptability, plugins, ...) of GNU make 4 could help you, if the build is complex. Also, use ccache and use parallel build: make -j 8 Aug 18 '14 at 14:14

If you write TDD-style code with low coupling, then it should be possible to compile and unit-test single .cpp files (or small groups of them) in isolation. You could create separate build files (makefiles, project files VS solutions, etc.) for each of these groups and develop them using a TDD approach.

  • Something like make will only compile changes as well if it is setup correctly. Feb 25 '11 at 23:00

I agree with nikie. If you're in a situation where you have a really slow compiling environment then you have to break things up so you can actually compile and test the input/output of the various objects/functions.

Even if I were writing in C, I'd still write small files and functions, fully test them, and then integrate them into the master application once I was certain that the code worked as intended.

   >  I am after a recommendations on how to learn these source 
   > code verification/error spotting skills again. 

What about pair-programming.

  • 4 eyes see more errors/flaws that 2 eyes
  • and you learn a lot about errors when thinking about questions like "why are you doing it this way?"