Ergonomics & mindset.
When it comes to working at a computer, ergonomics is always critical. Because debugging can be a hair-pulling task, it is best to remain comfortable with adequate lighting levels. The screen shouldn't be to bright, and the space in which you're working should provide adequate lighting. Programs like Flux can really help with ensuring your eyes do not get strained from lighting. A comfy chair that is adjustable, cushioned, and comfortable, along with good desk space will allow the programmer to not feel cramped and help reduce headaches and stress. So when debugging, if you're not following at least some basic ergonomic rules, you could be artificially stressing your body out.
Debugging is not just a task, it's a mindset. If you're not thinking logically about your problem and instead pulling your hair out, screaming internally about why the $#^% that particular part of your program won't work, you could be debugging wrong. Panicking is exactly what you should do if you want to not debug correctly. In fact, here is a list of things not to do from a mental standpoint
Debugging is not just a task, it's a mindset. If you're not thinking logically about your problem and instead pulling your hair out, screaming internally about why the $#^% that particular part of your program won't work, you could be debugging wrong. Panicking is exactly what you should do if you want to not debug correctly. In fact, here is a list of things not to do from a mental standpoint
- Panic (probably the worst thing you can short of going postal).
- Don't take breaks, don't drink water, don't talk about the problem to anyone, don't do anything to give your mind a break!
- Berate yourself verbally (calling yourself an idiot, for example. We all make dumb mistakes)
- Physically harm yourself (head desk, hair pulling, hitting yourself on the head. Yes, I know someone who smacks their head when debugging and he gets a headache every time).
- Point fingers at co-workers, peers, etc. This will only make things worse.
- Get angry at the problem
Sometimes a little stress is good as it can motivate without causing any actual harm. However, if you let stress rule you, you won't be a good debugger, just a stressed out programmer.
Shotgunning and hacking in code
A term I first heard from one of my TA's, shotgunning code means when you just write code into your program and hope it works, without actually looking into the problem. Sometimes, this approach will work, especially for smaller programs, but you won't figure out why and you certainly won't learn anything. The problem with code shotgunning is that you can spend hours just spraying if statements here and there, tweaking little values, adding in new junk, and by the end of it even if you got it working you probably won't understand how you got it to work.
Code hacking can be just as bad, if not worse, because it turns shotgunning code into a bad habit. Sometimes programmers will encounter a problem and discover a fix but not understand how it fixes it but use it anyways. That isn't learning how to debug, that is having a bag of trick to fix niche issues you don't truly understand.
Comments, documentation, and code structure
If you want to be a bad debugger, do these:
- Don't comment, or not often enough.
- Have weird variable names.
- Spell words incorrectly.
- No documentation or poorly written documentation
- Don't plan. At all.
- Don't have any flow charts, diagrams, or any indication of how your program is structured.
If you don't do these, you're not helping yourself or anyone who could be looking at your code. Commenting code is so critical to writing code that will help you fix problems it isn't funny. How many times have you written some code into the wee hours of the night, didn't comment, then came back and looked at it and you had to figure out what it did, just to jolt your memory. If that sounds familiar, then try commenting more with additional clarity. Comments are meant to help someone understand the who, what, where, why, when, and how of code so programmers can understand it easier.
 |
| Good advice, but you don't HAVE to follow this exact method |
Weird variable names and proper spelling is quite obvious. If your variable names are spelt wrong, programmers will have difficulty finding it. Weird variable names simply means if you're supposed to have a bool that checks if the player goes first during a game of Tic Tac Toe, call that bool isPlayerGoingFirst, not playerMove, or isPayerGng1st, because that will down right confuse people.
I don't think I can stress how important documentation is to code, more so third party libraries or a tool you made for a group project. SFML is an example of good documentation. It has lots of comments and describes how things work in short, brief statements. Nothing bad about longer explanations, but this works in a crisp and concise way. If you are going to code a menu creation tool, or a sophisticated object loader, comment about it and describe how it functions. You'll be happier for those comments if it has a problem.
Next step, plan. Seriously, plan your code. Buy a white board, markers, and plan a flow chart for your code. Don't know how to make one? Google it. Having a logical flow chart of how your program should go from point A to B to C and so on is stupidly important that if you don't do it, then it becomes harder to understand how your program works in the bigger picture of things.
 |
| This isn't hard to do. |
Conclusion
It is possible to write an entire book on how not to debug, but this is just a taste of how not to debug. Next time, I'll be discussing about how and how not to test your code by using actual examples, more in depth into how not to code, and some good practices I've learned over the years of coding.
