A huge amount of my time at work is spent debugging code I’ve written, or that somebody else has written. A lot of what I do ends up being trial and error – by which I mean try the code, read the error, re-write the code, read the new error, rinse, repeat.
Obviously a more sensible, systematic approach is needed, so I’m just going to make some notes on a few useful terms and tools to help get clear in my mind a few questions to ask myself when I encounter an error. This way I can assess what I’m dong, instead of blindly trying to modify code in the hope that it’ll work if I just tweak it far enough.
What kind of bug is it?
There are three main types of bug:
- Syntax error – where the incorrect syntax has been used (e.g. a misplaced semi-colon) and so the code cannot execute
- Runtime error – where the code executes, but does not run correctly due to a misconfiguration (e.g. insufficient memory or missing file)
- Logic error – where the code executes and works, but produces an unexpected/incorrect result (e.g.
It’s important to recognise what type you’re facing, as it might not actually be a problem with the code itself. In fact, more often than not, when I do encounter errors, it’s a configuration problem (requiring https over http seemingly comes up time and again for me), and in most cases, no amount of code-tweaking will fix that.
Can You Break This Down?
Breaking the code down into smaller chunks is good practices for so many reasons. By having small, quick functions that do a single, dedicated task, not only can you re-use them more easily within the same application, but they are also easier to debug.
If the bug lies somewhere in a huge piece of programming, it can be difficult to pinpoint. If it’s just a function that is expected to do one quick thing, you can write a test of that specific function and compare the results against what you expect. This is a good habit I’ve been trying to adopt for a while, but still find myself tempted sometimes to just pack a whole series of operations into a single function.
No! Break it up!
Some Notes on Coding Languages
PHP is quite a forgiving language when it comes to how the code is written, and so code containing problems that technically constitute errors can quite often still execute without issue. For this reason, it’s important to become skilful at identifying critical errors within error logs, as many logged “errors” are not in reality obstructive to the code executing. Of course, it’s best practice not to include any errors at all, but sometimes – due to time constraints – it’s necessary to adopt an attitude of “as long as it is working, don’t try to fix it”.
Usually PHP will output any critical errors on the page, and will specify exactly where the problem is, naming the file and even which line contains the incorrect code.
In CSS, I often make tiny typos that result in my styling simply not being applied. It’s very important to keep an eye on how things are nested and bear in mind parent-child relationships.
.container .wrapper is not the same as
.container.wrapper – the difference is tiny, but it can (and often does, at least for me), result in code simply not working.