– What is static program analysis ?
Static program analysis allows the gathering of informations about the execution behaviour of your code without actually executing it. It is the opposite of dynamic program analysis (like debugging) which required the code to be executed.
– Ok! But why should I use this in practice ?
- To save time by suppressing the save/execute cycles induced by syntax errors (missing “;”, function or variable not initialized, typos, …). Correcting these errors at the debugging step (dynamic analysis) requires that you write, save, (re)compile or (re)execute your program multiple times.
- To gain in performance by identifying libraries/variables/functions that are not initialized properly or not use at all. A must, for self-taught programmers or for those who do not have a lot of coding experience.
- To gain in readability by following some well established stylistic rules developed by a group of programmers. These rules are a standard to adopt. Quite helpful to learn a new language!
– Ok, I’m interested, how does it work?
It depends on your programming preferences. Do you write your code in a text editor or in an integrated development environment (IDE)?
Static analysis tools are already integrated in most of the IDE. Or language specific plugins are available for you to install (for example, PyDev for python in Eclipse). Those tools will directly highlight hence identified errors in your code (it works like a spell-checker).
For those of you who prefer simpler text editor (like me!), small programs (namely lint or linter) can be added to your favorite editor
(emacs, vim, sublime text, …). Here, your errors are also highlighted in your code. A quick look at your program is all is needed to spot them and correct them quickly.
Errors are in red (Undifined name ‘Tot’) and the warnings are in yellow (imported but unused).
If there is no linter available for your text editor, you can install one and execute it in the console. A list of errors and warnings will appear in the console; it is less convenient but better than nothing (faster and better than classic debugging).
If you’re not sure which solution to choose, I recommend that you try Sublime Text with the package sublimeLinter. It’s really easy to use and very efficient. It also has a package manager which facilitates the installation of the linter.
Get yourself started with Sublime Text here.
A few comments:
– Linting isn’t really what people have in mind when they mention static code analysis.. SonarQube and Moose are more what the term implies, although strictly speaking, linters really are a type of static analysis (since they use only the source and don’t rely on evaluation or compilation). Basically, when people are interested in whether there are typos or missing/extra libraries and references and/or basic stylistic mistakes (in python, the most common class is having used tabs instead of spaces or having used too many/too few spaces per indentation level), they use a linter. If they want to know if there is duplicate code, inefficient paradigms (“code smell”), bad variable names (by some criteria), likely memory leaks or out-of-bound accesses, etc., they use “static analyzers”. Advanced “static analyzers” can also reason about the program in complex ways (this veers into formal verification territory, but the combination of static analysis and formal verification is its own thing).
(So in conclusion, I oppose your choice of titling this article “be better at programming with _static program analysis_” since you only discuss linting).
– A cool thing with emacs and vim is that they can offer errorlists and locationlists (it’s similar to how your IDE is pointing you toward the error in your code, the locationlist or errorlist records the line/character and text of the error and you can automatically jump to the code at the line of the error by selecting the appropriate line), which is more practical than, say, ctrl+z -> flake8 -> fg. Most language plugins will automatically set this up (and even possibly run it on the fly). Otherwise, in vim (which I’m more familiar with), one simply sets the makeprg and errorformat variables, then issue a :compiler command once (not always needed) and :make whenever the linter should be run. No need for an external package and no need to “add” a particular linter or to even build any particular compatibility script!
You are not the audience I was aiming for this blog.
I have change the title to avoid misunderstanding.
Thank for your friendly feedback and share your experience for more advanced users.