Tooling for Type Consistency and General Validations

In this section, we'll explore how to configure some basic tools and automatically run checks on code, with the goal of leveraging part of the repetitive verification checks.

Remember that code is for us, people, to understand, so only we can determine what is good or bad code. We should invest time in code reviews, thinking about what is good code, and how readable and understandable it is. When looking at the code written by a peer, we should ask questions such as:

• Is this code easy to understand and follow for a fellow programmer?

• Does it speak in terms of the domain of the problem?

• Would a new person joining the team be able to understand it and work with it effectively?

Importance of tooling

Code formatting, consistent layout, and proper indentation are required but not sufficient traits to have in a code base. Moreover, these are things that we, as engineers with a high sense of quality, take for granted, so we read and write code far beyond the basic concepts of its layout. Therefore, we are not willing to waste time reviewing these kinds of items, so we can invest our time more effectively by looking at actual patterns in the code in order to understand its true meaning and provide valuable results.

All of these checks should be automated. They should be part of the tests or checklist, and this, in turn, should be part of the continuous integration build. If these checks do not pass, make the build fail. This is the only way to actually ensure the continuity of the structure of the code at all times. It also serves as an objective parameter for the team to have as a reference. Instead of some engineers or the team leader always having to point out the same comments about PEP-8 on code reviews, the build will automatically fail, making it something objective.

The tools presented in this section show some of the checks that can automatically be performed on the code. These tools should enforce some standards. Generally, they're configurable, and it would be perfectly fine for each repository to have its own configuration.

The idea of using tools is to have a repeatable and automatic way of running certain checks. That means that every engineer should be able to run the tools in their local development environment and reach the same results as any other member of the team. And also, that these tools should be configured as part of the Continuous Integration (CI) build.

Checking type consistency

Type consistency is one of the main things we'd like to check automatically. Python is dynamically typed, but we can still add type annotations to hint to the readers (and tools) about what to expect in different parts of the code. Even though annotations are optional, adding them is a good idea not only because it makes the code more readable, but also because we can then use annotations along with some tooling to automatically check for some common errors that are most likely bugs.

Since type hinting was introduced in Python, many tools for checking type consistency have been developed. Let's take a look at two of them: mypy and pytype. There are multiple tools that can be used, but in general, the same principles apply regardless of the specific tool: the important part is to have an automatic way of validating changes, and adding these validations as part of the CI build.

The mypy option is the main tool for optional static type checking in Python. The idea is that once we install it, it will analyze all of the files in our project, checking for inconsistencies in the use of types. This is useful because, most of the time, it will detect actual bugs early, but sometimes it can give false positives.

We can install it with pip, and it is recommended to include it as a dependency for the project on the setup file: