Harry R. Schwartz

Software engineer, nominal scientist, gentleman of the internet. Member, ←Hotline Webring→.

· 1B41 8F2C 23DE DD9C 807E A74F 841B 3DAE 25AE 721B

Casual Static Analysis

Published 15 Jun 2016. 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.