Here’s a tutorial I made some years ago and posted to YouTube.
In this tutorial, I create a pricing and discount application and use it to show, in simple cases, how anyone who writes code, regardless of skills level, could encounter issues in logic and how to think through them. The examples I share are just one of the number of ways to approach the logical thinking needed to solve problems when your code doesn’t work the way you expect it to.
I have used a simple example in the video here to show especially beginner and intermediate-level programmers how to think through code problems and debug their applications .
Debugging your code is a must as you build your application. Implementing additional requirements forces you to introduce new code logic to solve problems. Often, what starts as just a few lines of code inside a few methods grow into additional methods with so many code lines written to perform needed actions.
The result: bugs get introduced into code that previously worked and the developer has to retrace his or her steps to figure out how newer code plays with existing one. Individually, separate code may be correct on their own and do exactly what you intend them to, so it’s not necessarily about the rightness or wrongness of a given code line or block as an individual piece.
But in interacting with other code which implement other requirements, a block of code could go wrong because the problem it solves is in complete disagreement with the problem solved by other pieces of code. Or it could simply run amuck considering the bigger picture of the application’s requirement. That’s a bug right there.
Having an expansive knowledge of the syntax of the language you work in is a plus in problem identification and solving. Helps you quickly decide what is needed, what next could be applied. Very often, very experienced developers are able to look at code and quickly see what could possibly be causing the issue, even without looking at the error list. Such ability comes from a lot of experience in having encountered such problems or other related issues in the past. But for newer and averagely skilled developers, more head-scratching may be needed to get to the root of a problem and dig out of the hole.
Bugs could be of different flavors, for example, syntax related or just plain logic issue type bugs. Syntax issues are easier, as you can quickly find out what your problem is, thanks to displayed errors. While they may not necessarily be so easy to solve every time because they may be subject to a larger error, the solve-one-problem-and-generate-another type error, the advantage of syntax errors is that you may have a quick head-start for starting your search for solutions.
Logic problems, however, are a different animal. Here, all your code may be syntactically correct and, as far as you can see, play well with other code blocks in the same or other inherited classes. But your application may not be doing exactly what is intended for it to do. This is a bigger problem and you’ve got to figure out what’s wrong.
Since the problem is unlikely to be in the code itself as written, it is usually in the code as it is implemented, hence the wrong result. So a good way to start is by choosing a break-point and using the debugger to step through your code line-by-line, if your development environment has one. Hopefully you are able to see the values returned and compare them to what the expected correct ones are – a good starting point. Now, you have to figure out how to solve the problem.
Sometimes solving the problem may require re-positioning lines or blocks of code within a method, deciding what should be in and where, what should be out, or where an assignment to a variable needs to be initially introduced (very critical). Since the computer (in this case, the run time) is “stupid”, follows your instructions blindly, and will not be so kind as to help you think anything out, you’ve got to give it the exact right instruction for it to throw back the exact right result at you. Remember that when it comes to the correctness of code, the in-built classes and libraries don’t think for you. You do. It’s like driving a car.
But beyond just giving the right instruction, you’ve got to know exactly where it is right to give it, at what point in your code flow an instruction needs to be introduced so that it’s not too early or too late for other instructions that rely on it.
One good way to solve logic problems is to think about precedence as you code. What lines of code lead to something happening and in what sequence should they be interpreted by the run time? Are you putting the cart ahead of the horse? Did you branch your code out so much that you got lost in the weed? Do you have pieces of code that were useful earlier to the overall big picture but need to be re-written or struck out altogether? Did you derive a result earlier that is a decision point from which other results subsequently feed off of, which makes other follow up results automatically wrong should the result of the decision point be buggy? Did you first think through how to implement your program before writing the first line of code?