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.

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.

share|improve this question

closed as off-topic by gnat, MichaelT, Bart van Ingen Schenau, BЈовић, jwenting Aug 18 at 9:53

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions seeking career or education advice are off topic on Programmers. They are only meaningful to the asker and do not generate lasting value for the broader programming community. Furthermore, in most cases, any answer is going to be a subjective opinion that may not take into account all the nuances of a (your) particular circumstance." – gnat, MichaelT, Bart van Ingen Schenau
If this question can be reworded to fit the rules in the help center, please edit the question.

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 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 –  Basile Starynkevitch Aug 18 at 14:14

3 Answers 3

up vote 9 down vote accepted

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.

share|improve this answer
    
Something like make will only compile changes as well if it is setup correctly. –  Matthew Scharley 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.

share|improve this answer
   >  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?"
share|improve this answer