Casual Static Analysis
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 grep
ped 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: