Programmers often wait for their code to return something. Perhaps it’s JSON from a REST endpoint you hit from the client. Perhaps it’s a record from a database you queried from the server.
Perhaps it’s the human, coming home with treats.
Thankfully, we can do other stuff while we wait! A program can continue executing other code while requests for external resources continue to sit patiently in the background, stepping out of the way so that other code can continue to run. When the code that was waiting on something finally receives that thing, it can then follow up by doing something that it was holding off on doing until it first got what it needed.
To keep up the dog analogy a little longer — this behavior equates to the idea of a dog waiting for its owner to get home before it is let out to do its “business”. However, while the dog is waiting, it chews up a pillow, runs around the house eight times, and barks for twenty minutes. Those actions weren’t dependent on the human returning, so they just happen. Thankfully, the dog at least knows to hold it in the meantime.
This idea of non-blocking code execution is called asynchronous programming.
What is a promise?
MDN’s page on the
Promise object nails the definition, so I will defer to them:
Promiseobject represents the eventual completion (or failure) of an asynchronous operation, and its resulting value.
The promises originated in the realm of functional programming, generally to handle asynchronous programming. In short, they allow us to define how data that will only be available in the future will be treated, specifying what will be done with that data later.
The promises were introduced in the standard in ES6, the truth is that they have been used for a long time since several libraries had implemented them to solve their needs in a more elegant way.
The Promise object represents the eventual completion or failure of an asynchronous operation and its resulting value.
Callback: A callback is a function that is passed into another function as an argument to be executed later.
Events: Events provide a dynamic interface to a WebPage and are connected to elements in the Document Object Model(DOM), for example: onclick(), onmouseover() etc.
Pending: Before the event has happened, the promise is in the pending state.
Settled: Once the event has happened it is then in the settled state.
Fulfilled: Action related to the promise has succeeded.
Rejected: Action related to the promise has failed.
Static code analysis refers to the technique of approximating the runtime behavior of a program. In other words, it is the process of predicting the output of a program without actually executing it.
Lately, however, the term “Static Code Analysis” is more commonly used to refer to one of the applications of this technique rather than the technique itself — program comprehension — understanding the program and detecting issues in it (anything from syntax errors to type mismatches, performance hogs likely bugs, security loopholes, etc.). This is the usage we’d be referring to throughout this post.
“The refinement of techniques for the prompt discovery of error serves as well as any other as a hallmark of what we mean by science.”
We cover a lot of ground in this post. The aim is to build an understanding of static code analysis and to equip you with the basic theory, and the right tools so that you can write analyzers on your own.
We start our journey with laying down the essential parts of the pipeline which a compiler follows to understand what a piece of code does. We learn where to tap points in this pipeline to plug in our analyzers and extract meaningful information. In the latter half, we get our feet wet, and write four such static analyzers, completely from scratch, in Python.
Note that although the ideas here are discussed in light of Python, static code analyzers across all programming languages are carved out along similar lines. We chose Python because of the availability of an easy to use
ast module, and wide adoption of the language itself.
Before a computer can finally “understand” and execute a piece of code, it goes through a series of complicated transformations:
As you can see in the diagram (go ahead, zoom it!), the static analyzers feed on the output of these stages. To be able to better understand the static analysis techniques, let’s look at each of these steps in some more detail:
The first thing that a compiler does when trying to understand a piece of code is to break it down into smaller chunks, also known as tokens. Tokens are akin to what words are in a language.
A token might consist of either a single character, like
(, or literals (like integers, strings, e.g.,
Bob, etc.), or reserved keywords of that language (e.g,
def in Python). Characters which do not contribute towards the semantics of a program, like trailing whitespace, comments, etc. are often discarded by the scanner.
Python provides the
tokenize module in its standard library to let you play around with tokens:
code = b"color = input('Enter your favourite color: ')"
for token in tokenize.tokenize(io.BytesIO(code).readline):
TokenInfo(type=62 (ENCODING), string='utf-8')
TokenInfo(type=1 (NAME), string='color')
TokenInfo(type=54 (OP), string='=')
TokenInfo(type=1 (NAME), string='input')
TokenInfo(type=54 (OP), string='(')
TokenInfo(type=3 (STRING), string="'Enter your favourite color: '")
TokenInfo(type=54 (OP), string=')')
TokenInfo(type=4 (NEWLINE), string='')
TokenInfo(type=0 (ENDMARKER), string='')
(Note that for the sake of readability, I’ve omitted a few columns from the result above — metadata like starting index, ending index, a copy of the line on which a token occurs, etc.)
#code quality #code review #static analysis #static code analysis #code analysis #static analysis tools #code review tips #static code analyzer #static code analysis tool #static analyzer
According to an analysis, a developer creates 70 bugs per 1000 lines of code on average. As a result, he spends 75% of his time on debugging. So sad!
Bugs are born in many ways. Creating side effects is one of them.
Some people say side effects are evil, some say they’re not.
I’m in the first group. Side effects should be considered evil. And we should aim for side effects free code.
Here are 4ways you can use to achieve the goal.
Just add use strict; to the beginning of your files. This special string will turn your code validation on and prevent you from using variables without declaring them first.