I have read somewhere that the cost of resolving bugs increases if it is not resolved at the initial stage. Which approach should I take while creating programs?
Divide program development in modules. Complete coding one module. Fix ALL bugs of that module before starting coding other modules.
Divide program development in modules. Complete coding all modules. Then start fixing bugs in the whole program.
Which of these approaches is better, and why?
What you've read somewhere is very true. When working on software you want to minimize all your feedback loops (this is the main principle behind agile/lean development). The sooner you find out that a correction is needed, the easier (effort, risk...) it will be to make that correction.
So if I had to choose between the two approaches you listed, I would go with (1), develop/test module at a time because the other approach has the largest feedback loop that you could possibly have. Writing entire program and only then testing it is asking for disaster.
However, I want to point out few more things to you:
It seems you are assuming that "a bug" is a coding error. And yes, coding errors are bugs, but when building software you also need to be aware of other bug types:
Neither one of your approaches is good for finding these other types of bugs. And just like coding bugs are cheapest to fix as soon as you write them, requirements and design bugs are also cheapest to fix as soon as you decide on strategy and before you write too much code. After your program is mostly done, design bugs become way more expensive than coding bugs. And requirements bugs often mean you need to completely rewrite a chunk of your program.
In other words, picture that your program consists of a few modules. You write and test the first module and everything looks good. Then you write and test second and third module and things still look good. Then you go to put them together only to discover that module A's design isn't really adequate in order to integrate efficiently with module B. So now you are back, redesigning, coding and retesting module A, which you though was already done. Time will be wasted.
Better approach would be to come up with high level architecture (general module layout) for your program. Maybe you have a UI, some business logic, some communications modules and data storage. Write a bare minimum (essentially just a skeleton code) in ALL modules and then test the whole program. Even if all it does is start up and shutdown without any useful work. Make sure start up works. Then add one feature to the program. This feature will likely span many/all of your modules. Test to make sure the feature works. Continue doing this until your program is done.
This way you will not spend too much time in module A before understanding how the whole program comes together. You will also be able to see live UI and you will be able to interact with it, so if something needs to change you'll be able to make adjustments before too much other code is written.
Managing bug resolution really needs to be handled on a case by case basis, and scheduled according to both business needs and the nature of the bug itself.
With that said, if you identify a bug while you are working on some code, and if the bug will affect your ability to continue implementing a feature, then it is probably better handled relatively quickly, and therefore scheduled as a priority. If however the bug is found but not directly affecting the feature you are implementing, then you need to log it, and at a minimum do a little debugging to determine the extent and severity of the bug found, then schedule accordingly, either at the end of an iteration, or at the tail end of a project, or even as a part of post-release maintenance if the bug isn't very likely to appear, or is not very severe in nature.
Ideally, we would all be writing software without bugs. The nearest we can get to this ideal however, is to write software in a way that ensures we minimise the opportunities for bugs to appear. This is where following ideals, such as SOLID, Clean Code, Behavior/Test driven development, YAGNI, Refactoring, and all of those other lovely little buzz-words we're so addicted to can be of great benefit. In particular, the key is to keep our designs and code things simple, lean, and a clean as possible, and with a high degree of test coverage. Essentially heading the problem off early in order to avoid the bugs getting out of control early.
Of course, you'll never really overcome those bugs that come about as a result of poorly understood requirements, and imperfect logic, but with a good methodical approach to developing robust software from the outset, you'll effectively reduce the amount of bug hunting you'll likely need to do later.
There are generally two problems in delaying bug fixing: 1) You don't know how long it will take to fix them; 2) Other parts of the code that depends on the buggy part will either be buggy as well or work fine until the bug is fixed (and later become buggy).
For the first problem, it's important that you keep track and prioritize bugs, since in practice is hard to fix every single small thing you come across right on the spot (especially if you're in a deadline). If a bug must be fixed before a particular release, then fix it as early as possible, so you can better manage your schedule (eliminating the imprecise task, the more precise ones will get easier to manage).
The second problem, however, is very significant: unless your design is particularly clear (so you can keep track on which parts of your program depends on which other parts) delaying bug fixes will likely introduce many more problems, and it gets worse the more time it passes. For this reason, developing modules that depend on it before fixing its bugs is more often than not a recipe for trouble.
So, my answer to your question is: you don't necessarily need to fix all bugs in a module before proceeding to the next, but if module B depends on buggy module A, fix all known bugs in A before starting coding module B.
Its depends on your requirement of project.If your project contain module those are pretty much independent then you can divide your project in module and then test by them as unit, fix bug.Finally integrate all module
But second case, If module are highly related and they have strong communication among them.Then we can not test a module independently .So you should code first and test as much as possible functionality you can test.Then go for complete testing after integration and fix bug.
In second case it increase overhead on a developer.
