BUGS

Bugs. One of the most dreaded words when it comes to programming. While oftentimes, bugs can be annoying, they can also be therapeutic for developers. It is a bitter-sweet experience. Whenever you hear a developer scream “YESSSSS!” out of nowhere, just know they just fixed a bug (or got a different error). While you do not want to live with them, you also cannot live without them as developers. The only thing you can do is learn how to better handle them.

This article is focused on practical steps to get bugs solved easily. There are two major ways to deal with bugs.

Preventive Measures

They say the best way to fix something is to prevent it from happening and this is especially true with bugs. While you cannot do without bugs, you can prevent most of them. About 70 percent of your bugs will be avoided if you follow the following.

• Write Clean Codes: Properly indenting your code works wonders for you over time. If you find it difficult to do, you may install an extension that automatically indents/formats your code for you. One of those extensions is the “prettier” extension available on Visual Studio Code. Writing very clear variable names and function names also helps. For example, If a function is used to check account balance, then name it exactly that, function checkAccountBalance as opposed to function cab. Believe me when I say you will not remember what the code does when you check up on it after a while.

  function checkAccoutBalance(){
  //Your code here
}
  function cab(){
   //Your code here
}

• Naming Conventions: There are various naming conventions such as PascalCasing, snake_casing, camelCasing and so much more. You should learn one, especially the one applicable to your programming language, and make use of it when naming your variables and functions. A lot of your bugs may come from not consistently using a naming convention.

• Leave Notes through comments: Leaving descriptive notes about what your variables or major functions do will help you easily navigate your codes. If the code belongs to an organization, the developers that will work on it will also bless you.

• Continuously test your codes: I understand you are a senior developer, and I absolutely agree. I understand you can type a million lines of code in one minute and you can build a complete e-commerce application in one hour but as much as you're tempted to, do not fall for the temptation. One of the best ways to prevent unnecessary bugs is to continuously test your codes as you are writing them. You will easily identify where there could be issues rather than debugging after you’ve written a million lines of code.

• Modularization: This is simply ensuring that you break your codes into single functional components. You really want to break your code into smaller chunks so it becomes really easy to find where an issue is or may occur than when you have a thousand lines of code on the same page.

• Write your own codes: I cannot over-emphasize this. The code you did not write yourself will be difficult to understand, and if it is difficult to understand, it will be damn near impossible to fix if and when it has an issue. Take out time to truly understand your tech stack fundamentals and write your own codes. Enough of copying and pasting every line of your code. Not to shake any tables but If it is always a case of copy and paste, then can you really call it your code after all?

• Throw Errors: This may sound counterintuitive but believe me when I say it works wonders. If you want to catch a bug, then throw the error (See what I did there?). A lot of developers don’t throw errors through callbacks to check if a particular function actually worked, especially if it is an external function. It means even when you face the bug, you may find it incredibly difficult to know which line that bug is coming from.

Corrective Methods

• Face it head-on: A lot of developers tend to for one reason or the other, just give up immediately because their codes do not work the way they expect. Relax, it will happen, and the earlier you accept that it is perfectly normal, the better. Every Developer faces it, you are not the first and you won’t be the last. Accept that you have a bug, and be ready to face it. What does not kill you only makes you stronger.

• Read and Understand the Error: Luckily for us developers, our codes do not leave us without a comforter. We have access to the console which displays what the error message is (most times) and on what line of code it is on (most times). What you want to do is not cry your eyes out, but take out time to read the error message, understand it, and then go ahead to read the line of code and see what could be wrong. A huge percentage of bugs are solved this way. By actually reading the error message and attempting to find out why.

• Commenting and Uncommenting: This especially works great when your code does not throw any visible error. At this point in time, you are at the mercy of your codes. You may now comment all your codes and begin to uncomment sections of them. This is exactly like trying to find where a person’s pain point is, you try a part, and if it isn’t, you try another part until you find where the major issue is.

• Documentation: Every external package or library has official documentation and most of them are actually quite explanatory (while some of them may confuse you even more because they come right from the pits of hell). Most of the issues you may ever encounter usually have been addressed in that documentation. Read it and learn from it.

• Google/Stack Overflow/Youtube: Everyone does it, don’t be deceived for Google is not mocked. Chances are that someone has faced that same issue you are currently facing before and has left their fix online (An habit you should also practice). However, this should be your last resort after you have tried all other options. After you have found the solution, try to understand it and not just copy-paste the solution. It will help your growth as a developer so that if you come across the same issues, or someone around you or online does, you know exactly what to do.

Conclusion

A famous developer once said to his codes, bug me once, shame on you, bug me twice, shame on me. (No developer said that I think!). In other words, if it took you over 3 days to fix a bug, the next time you or someone else faces the same bug, you will use only 3 seconds to smash it. You’ll look the person in the eye like a superhero and tell the person, I've been here before, smashed it, and here is how to smash it too.

Did I miss a tip that could be helpful? Then kindly leave them in the comments. Was this helpful to you? Then kindly leave them in the comments. Lastly, do well to share and subscribe to get more content like this so other people can come across this. Thank you 🤗🤗🤗

P.S This is my first ever blog on hashnode or anywhere else really and I'd really appreciate pointers on what to do better. Thank you 🤗🤗🤗

#javascript #4articles4weeks #bugs #week1