How do you debug your code?
For the longest time, Flash provided very little in the way of built-in code debugging. Beyond syntax checking and (more recently) type checking, developers were left to fend for themselves. Over the years, we’ve seen quite a few varied solutions ranging from debugger classes and components, several more robust 3rd party editors and assorted unit testing methodologies imported from ‘real’ programming languages. Yet, at the end of the day, we still don’t have an ‘easy’ button (ala Staples), that when pressed, tells you where your cockups lie. So, we make do with what we have, developing and (hopefully) sharing our own processes, getting incrementally better but still wanting.
I have spent the last few days refactoring my own (Clinton-era) debugger class, knocking off items from my TODO list, adding a couple of features and fixing or removing a couple more. I will hopefully have it ready to post here soon, most likely as part of an introductory release of mPerfect. In the meantime, I would love to hear from others how they debug their code.
Hi,
I had developed a unit testing component, used it for a while loved it. I need to stress how important unit testing should be unfortunately I ended up not using it on short deadline projects (where it should be the most helpfull)
You can find all the lecture notes which include links to 3rd part testing tools at:
http://www.reflektions.com/lectures/
Cheers
April 4th, 2006 at 8:36 amThanks, Paul. I actually attended your FFSF05 session and was thinking of your work when I mentioned unit testing in my post. I find your approach to be very inspiring. However, I haven’t been able to justify unit testing in Flash development (HERESY!), primarily for the reason you mention.
Practically (and philosophically) Flash is so different from other more traditional platforms. Despite the maturation of the ActionScript language, I believe the demands and expectations of Flash remain rooted in the past. Flash is still perceived by most in our industry as a tool for rapid prototyping, animation, GUI development, etc. We are seldom given more than a couple of months (often only a few weeks) to build and test our applications. Knowing what an application does and how it does it before building it is a luxury we are rarely afforded.
That being said, it is not necessarily a bad thing. While it makes sense to incorporate many of the techniques and processes that programmers in other languages have spent decades improving upon, it’s important to remember that Flash IS different. Flash is SPECIAL
. As such, we have a different set of tools that we can use to accomplish our goals and plenty of room in the margins to noodle on ideas – kind of liberating, really.
April 4th, 2006 at 11:27 am