Creating quality code is an amazing process, and seeing your product run beautifully without crashing is another heavenly feeling, but bug free code highly unrealistic. Therefore lets go through some bug crushing ideas to help us get that intoxicating feeling while writing less bugs.
One of the things I learnt painfully was that trying to re-invent the coding was working against me, so a major part of me creating less bugs actually came from sticking to standard, by writing code using the docs as reference. So I have to emphasize that learning to use documentation, and learning it correctly will greatly reduce the amount of bugs you create.
Using the docs also makes the types of bugs you meet predictable, we might not avoid them totally, but usually following standard creates a possibility that the issues you face was surely faced by other developers and the solution shared online your job is to find it.
Understanding documentation also gives you the power to copying and pasting a bug fix with confidence to even modify it. It allows you to understand the solution and be able to replicate or create a solution for a similar problem in that same domain.
Another benefit of sticking to the docs is that if you failing to debug, whomever you ask for help will in-fact get to the source of the bug quicker and solve it easier, this is because you wrote code in a way it is generally used or with general behavior.
A sad reality is that us juniors actually get so stressed with error messages we prioritize removing the message not truly fix the bug that cause it, that’s why some bug fixes produce more bugs but we can change that.
Read your stack trace carefully, follow the error messages to find where the exception was thrown, some times the debugger will show you where the bug is, it goes as far as showing the files affected 'as a hierarchy' therefore the one on top is likely the file with a problem, and next to the file name is a line number representing where the error is.
If the bug key words are foreign to you please don’t spend too much time on it, simply search the bug on google and look for a solution you can understand and modify, solutions that correspond with docs.
My most important point here is that do not try fix a bug before you fully grasp its and what it means and only then do you start implementing chose fixes.
One thing that my senior tend to always require from me was clarity, because without it you will definitely face logic errors.
One trick is to write single purpose code because this will allow you to re-use your code and not repeat yourself, but again this means when there is a bug you will narrow it down easily because you only one module / function does this functionality.
Apply that KISS rule “keep it simple and stupid”, when you have to write complex logic, simply separate it into small simple pieces initially, then when its working then remove any redundancies or any useless things that might make the code look longer and with millions of references.
Another thing my senior pressed onto me was reusing code. I later realized that this makes me efficient and allows me to write code on a standard I can't produce and good quality code is less buggy code, but obviously this cause bugs also if not clear about how a module or function you want to use works.
Clarity also allows us to see the possible errors that might happen, so we can use try catch clauses but with a intent keeping them on the minimum.
Your tools will also cause you that success or failure in a project so its recommended that we first update our tools, make sure everything is working correctly.
Make sure your frameworks dependencies are not clashing and that they updated, or just re install them, this some times causes bugs with building the project or running the project.
On a more personal note, learn how to use your dev tool and you debugging tools, for web developers using Chrome debug tools is the go to, but others are out there. UI designers use Adobe XD or Figma, but to be great at your work mastering the tool is key.
IDE's have built in debuggers for the languages they use and frameworks have those for the languages they accommodate, so once again that learning the debugger for that is useful for fixing bugs efficient and effectively.
Sometimes while writing code, the error or output tab will show you warnings, with VS you even see them before you compile the code. Don't work against yourself by ignoring these when you polishing the code, look through them and fix those also to avoid bugs creeping up on you later.
- The conventions will save you a lot of issues across the board, they allow us to write code in a clean way and much readable and understandable.
Using their naming conventions allow us to understand easily differentiate from names alone functions, variables, constants and so on.
Using comments correctly and on minimum will allow you to keep track of your thoughts when you made a decision and if it still matters and also anyone else who might need to know the logic behind the logic you have expressed in code.
you don't need to go deep into this but, at least applying the basics is enough for you to write cleaner code and be able to even understand why something is written in a certain format and why you could use it for yourself.
- Its true, working on a bug for too long is a thing and if you don't rest so it wont too.
- A useful process in developing and debugging is taking time off the screen. This is why some times fresh eyes can see simple errors you couldn't.
- So an easy fix some times will be to fully consume the issue of the bug then leave it to fix when you come back. The process of rest will allow your mind to see things differently, the feeling of being refreshed and calm is good for you to analyze get deep easy with.
A last important point to raise is being TDD “Test Driven
Development” which is one important practice because you don’t need to get too far in maintaining code then you realize you have bugs in runtime, “assuming these are not syntax but logical errors”.