Harry R. Schwartz

Code writer, sometime Internet enthusiast, attractive nuisance.

Vancouver

British Columbia

Canada

vegan


Casual Static Analysis

hrs

Published .
Tags: computer-science.

At PyCon a couple weeks ago I saw an excellent talk by Ned Batchelder on Machete-mode Debugging. It included a bunch of handy tips on temporarily monkey-patching, tracing, and exception-raising your way to finding bugs.

As I’m occasionally wont to do, I latched onto a particular throwaway reference Ned made. He mentioned that though Python was a dynamic language and most forms of static analysis didn’t really work, when we grepped through code we were doing a sort of primitive static analysis.

I really like that! When I think about static analysis, my mind usually goes straight to analyzing ASTs and checking types and building function call graphs. But static analysis is ultimately about extracting information about source code without running it, which grep totally does.

That got me thinking about what other kinds of “static analysis” I use every day. A lot of Unix utilities definitely count. If I’m browsing through a new code base I’ll use tree to see how files are organized (which usually gives me some insight into which things have similar functionality), and I might use wc -l to learn where the terrible god objects live. I’ll also occasionally use find to determine how many files there are of a given type.

What about version control? Using git log and git blame gives me plenty of information about a program without executing it. I’m not sure I’d count that as “static analysis,” exactly, since we’re examining the history of the source code instead of the code itself, but it feels related.


You might like these textually similar articles: