I’ve been developing some sort of software for the past 6 years as a part of my job.  Most of the code I’ve written has been non-production utilities and has followed a very unstructured process.  I see something that has to be done and try to find the fastest way to automate that task.  This definitely doesn’t always result in the most structured or commented code.  That’s gotten me into trouble when others attempt to troubleshoot the code. Heck, it can be difficult to troubleshoot my own code a while after it’s been written!

With Python, I’ve actually found most of the code to be easier to troubleshoot.  It’s really similar to MATLAB, which makes me happy.  Something about the rapid prototyping and easily understood syntax just makes it a breeze to program with.

Over time, I’ve found that much of the difficulty I have in writing readable code comes from parsing data and dealing with complex code structures.  Once a code structure gets beyond about 3 levels, I tend to start throwing temporary or intermediate variables around too much without enough explanation.  Then I end up with a variable name like this: input_signalname_simple_muxed[j]

When a latent error pops up with a variable name like that, it always takes a while to figure out what the heck it even means.  Maybe I could make the variable name more descriptive, but that doesn’t seem to be the right direction (shorter is probably better).  I haven’t really found a good way around my signal naming.  I usually don’t realize how big a problem I am creating for myself until I’m about a quarter of the way through a particular program.

Some refactoring does help the code, but sometimes the problems are too ingrained into the code to make a refactoring very easy.  That’s not a good way to create maintainable code.  To anyone who has (or has ever had) to troubleshoot my code… I’m sorry.  To be fair, I usually hate troubleshooting other peoples code.

Interesting Blogs:

Chris Dixon’s Blog

Seeing Both Sides

Seth’s Blog