1

Suppose there is a reasonably sized programming task(500 lines of code). Which is better?

1/Code the whole task from start to finish without running the code and debug later.
2/Code some small features, then test and debug, then repeat until the whole task is done.

Personally from my experience, sometimes the first approach saves time. But sometimes it takes multiple compile-run-debug cycles to get it to work.

The second approach works steadily, but sometimes it feels like it's not that efficient.

What are your experience on which is generally the better approach?

Improve this question
1
  • 1
    If you test task 1 as much as you should be, then task 1 would take almost as much much time as task 2 anyway. The temptation is always to assume that it works when the output is as you expect, but that doesn't cover every possibility in most cases. Test-driven development at least guarantees that your expectations for each piece is satisfied before moving onto the next and generally increases the probability that tested components working together will be less buggy than if you didn't do it that way.
    – Neil
    Dec 21, 2018 at 10:15

2 Answers 2

Reset to default
6

There is a reason why "Test Driven Development" has become extremely popular today - it lets developers write a little bit of test, a little bit of code, compile it, test a little (maybe debug it, if necessary) and refactor it - in cycles measured in minutes, not days or hours. So there is a broad consensus that it is definitely not a good idea to write a block of 500 lines of code and then let the code run the first time, see if it crashes (which it most probably will), and then start to look for all the possible root causes (which are many in a code block of that size).

There is only one situation where I can think of coding in larger steps and "debugging later" might save time - when you have very large turn-around times. When each build cycle takes 30 minutes or more, you don't want to compile, build and debug after every 10 new lines of code.

Fortunately, most development environments today don't impose such build times on the devs, and even in large-scale C++ projects, there are means available to mitigate such issues.

However, this is not only a matter of the environment, it is also a matter of structuring your project into components. If you can implement, say, 450 lines of the 500 total lines of your code in a separate component, which can be compiled and tested apart from the rest of the system (maybe using TDD, or at least using unit tests), then you can (and should) develop the component in as small code/compile/test/debug cycles as possible, even if a full build of your system would take more than an hour. Afterwards, you may finish the separate integration step with the final 50 lines of code "en block".

Improve this answer
-1

It is largely a question of taste - and your working memory (as in your brain, not your computer).

Processes such as TDD would tend to favour coding and testing small features at a time - the rationale being that you're best placed to write good tests and fix issues when the new code is fresh in your mind. We've all I'm sure found and fixed bugs that we realise would have been far simpler to fix when the thing was being coded if a little more care was taken.

Improve this answer

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