By James Edwards

Developing CodeBurner — An Exercise in Exploratory Programming

By James Edwards

A new version of CodeBurner has been released. This release does not rely on Firebug — it’s a standalone extension, and for a limited time comes bundled with a free book! Grab yours now.

Today we launched FireScope CodeBurner, a new add-on for Firebug that extends it with reference material for HTML and CSS.

As it turned out, developing for Firebug is not significantly different from developing any other Firefox extension. I’m indebted to Jan Odvarko for his series of posts on Extending Firebug, from which I got the basics that I needed to make it work — how to hook into Firebug’s scripting namespace, how to add controls to its user-interface, and how to make use of its available scripting objects.

But apart from a smattering of basic articles like that, Firebug’s API is essentially undocumented, and so I had to do quite a bit of what you might call “exploratory programming” — poking around in the source code to look for code that looks like it might do what I need. For example, FireScope CodeBurner needs to be able to extract all the CSS properties that apply to a given element, so that it can search the reference for information about each one. We already know that Firebug can do that, because it’s right there in the Style panel, but how do we hook into the right processes to get the information where and when we need it? Fortunately, since Firebug is open-source, there’s nothing it can do that can’t be discovered eventually, even if it does take some hunting!

The process I use to find functionality like this is a kind of reverse-engineering, where you start from the end result, and work your way backwards. For example, I began by looking for code that addresses the part of the user-interface where I know that CSS information is displayed, and I can look in Firebug’s XUL files to find out where that is (XUL is the eXtensible User-interface Language used by Firefox to define its UI components). Once I’ve found that code, and find that it’s contained with a method, I can then look back further still, for places where that method is referred to. And so on, through method calls and references, until eventually I find the code that actually extracts that information from the CSS DOM.

Although intricate and sometimes confusing, this process of reverse-discovery allows me to work through the most intricate and abstracted code, and is what makes it possible to build tools like this, that rely so heavily on functionality from an undocumented codebase.

It’s not something that appeals to everyone, because it takes a lot of time and a certain kind of patience, but I find it incredibly satisfying when it does all work out — and that’s what makes the process enjoyable for me.

How about you? Do you enjoy this kind of programming task, or does the very notion leave you cold?

  • Hawk

    Great tool! Thank you!

    The only thing I would ask is to include other browsers like IE6 and FF2. But mostly IE6 because like it or not we still have to make our sites work with that browser.

  • Tarh

    I do this kind of exploratory programming almost daily, as I work with a nearly completely undocumented C++ codebase with 100,000+ lines of procedural code. Also, due to the nature of the project, it’s not possible to run it in debugging mode.
    Luckily, the Visual Studio IDE has plenty of tools to help make this process easy. I’ve become a huge fan of the “Callers Graph” function, which basically shows a tree of all calls to a particular method and lets you quickly jump around. The “Find All References” function points out every single spot in the code which refers to a method, class, or variable. And finally, for all those sticky bits, the good old “Find and Replace” function can be used to find things that the interpreter can’t quite figure out.
    The process is completely backward. If you’re looking for code that does something, but you have no idea where it is, you start by thinking “what code would this method need to use in order to do what it does?” You can then find that child code more easily, and work your way back through the calls to find where everything originated. At this point you can use a debugger to scan the scope for the information that you need or, if you’re like me and don’t have access to a debugger for this project, you can resort to a few good ol’ “echo” statements! :-P
    It’s not easy, but assuming that you know the language and IDE that you’re working with quite well, it’s not that difficult, either.

Get the latest in Front-end, once a week, for free.