The Halving Method
Working a great deal with blacklists, I am frequently trying to isolate and identify problematic code. For example, a blacklist implementation may suddenly prevent a certain type of page from loading. In order to resolve the issue, the blacklist is immediately removed and tested for the offending directive(s). This situation is common to other coding languages as well, especially when dealing with CSS. Identifying problem code is more of an art form than a science, but fortunately, there are a few ways to improve your overall code-sleuthing strategy.
The Halving Method enables you to identify problematic code quickly and easily.
First
Firstly, think. I know this sounds trivial, but too many times do we as designers and developers get trapped into working as fast as possible, leaving our brains on “auto-pilot,” and immediately turning to Google as soon as something goes wrong. When it comes to diagnosing problematic code, your most valuable tool is your own mind. Take some time to do some critical thinking about the situation. What do you know about the issue? Has it been encountered before? What are the different components involved? And so on. Many times, I have found a relatively quick solution by simply slowing down, defining the issue, and assessing the variables.
Second
Secondly, check the obvious. Working at a rapid pace requires us to rely on heuristics and algorithms to facilitate expedient production. Unfortunately, this way of thinking generally relies on taking “mental shortcuts,” working in the present, and focusing on singularities. This modus operandi excels when events unfold according to plan, but leaves us clueless when unexpected snags pop up. A good way to transcend any momentary disorientation is to stop and review the basics. You know, those well-known and obvious things that are usually forgotten about whilst working diligently with higher level operations. Things like: “Is this the most recent version of the file?” “Is the script even compatible with IE6?” “Did I forget a closing bracket?” “Is the computer plugged in?” You know — the basics.
Third
And finally, the “halving method.” This technique is absolutely great for isolating and identifying problematic directives in blacklists, firewalls, and other behavior-altering portions of code. Additionally, I have used this method in lengthy stylesheets for determining which CSS declarations are causing unexpected behavior. The halving method basically works just like it sounds: when encountering problematic portions of code (such as a blacklist, firewall, or stylesheet), isolate the offending directive(s) by first removing one half of the code and checking for desired functionality. If things are still not working, remove another half of the code and test again. Wash rinse repeat. Then, as soon as proper functionality returns, replace the only the last portion of code that was removed and continue the process. Very quickly, usually after two or three iterations of this process, the problematic code will be easily identifiable.
7 responses to “The Halving Method”
Great post, and a reminder to use common sense. I had something similar happen when I installed the 3G Blacklist. All the CSS for my site was no longer visible. Rather than panic, and uninstall everything, I looked at the errors in the mod security log to see just what was giving me grief. Bingo, one rule was doing it. Removed that rule, and all was good again.
Anytime you’re doing anything with a computer, whether troubleshooting a software problem, operating system issue, or configuring your WordPress, it’s always a good idea to backtrack one step at a time. I.E., what did I just do that may have caused the issue.
Hi Sue, thank you for the comment. You are absolutely right that backtracking one step at a time is another very effective method of troubleshooting conflicting code and other issues. I should have mentioned that in my article. Common sense is always the best approach for dealing with the logical nature of web design and development. Also glad to hear that you resolved the conflict with the 3G Blacklist. Btw, I am currently beta testing the next version (4G) of the blacklist and it should hopefully be released very soon. Stay tuned!
Also, you don’t even necessarily have to *remove* the code in order to isolate the problem. What I often do, is simply turning the bits that I think are correct into comments.
For example, rather than removing a few CSS definitions, you can make the browser ignore them. Like so:
In this case, the margin and padding will not be seen by any browser. When you’ve found the problem, you can simply remove the redundant comment-characters, rather than pasting or redoing the whole bit.
The same principle can be applied to HTML, PHP or any other programming language that supports inline comments.
**Critical edit:
What I often do, is simply turning the bits that I think are *INCORRECT* into comments.
Sorry.
Hi Adrian, thanks for chiming in! That’s indeed another useful troubleshooting tip that should have been mentioned in the article. In essence, you are “removing” the code by commenting it out, however your point is clear — it is often more expedient to disable code (via comments) than it is to physically remove it from the document.
Also, concerning the troubleshooting of CSS, if you need to disable an entire declaration block, it is easier to simply “
x” out the selector rather than fiddle with opening and closing comment characters.For example, if I needed to disable the
#pancakesselector for some quick troubleshooting, I would simply do this:Which would have the effect of not matching the target selector, so the styles would not be applied. Also, re-enabling the code is just as easy — drop the
xand you’re good to go!Languages like JavaScript and PHP which support single and multi-line comment syntax can also use this little trick:
The Comment Toggle:
…but remove one of the slashes from the first comment line…
Once more, with proper entities:
…but remove one of the slashes from the first comment line…