How to Audit the Quality of Your Python Code: A Step-by-Step Guide (Free Checklist and Sample Report Inside)

After reading the section above, you might think: okay, but everything you’ve just described can be achieved with the help of a code review, and we run these regularly!

It’s true that the terms might sometimes be used interchangeably, but there are a few subtle differences between them. 

Code review is contained within one team—the developers review each other's code, and they focus only on one specific part.

A code audit, on the other hand, always concerns the whole project and is performed by a person outside of the team—be it other developers, or even an outside company.

While code reviews are useful and necessary, performing a code audit every once in a while makes a tremendous difference. Let me use another metaphor here: reviews are like checking different parts of your car for potential malfunctions. Of course, it’s necessary to see if the headlights operate correctly, if both wipers are fine, and if your brakes do their job… But unless you start the car, take a drive, and assess how everything works together, you won’t know how good the whole machine actually is.

As the unwritten rule goes, the more people see your code, the better. And the more you fix, the more faultlessly the project will perform in the long run.

For a limited time, we can run a free code audit for you. Our senior developers will help find any potential issues, make recommendations on how to fix them, and advise you on how to improve the quality and maintainability of your code.

The offer is limited, so the code audit is offered on a “first come, first served” basis.

Head over here to schedule your free code audit from STX Next.

In the beginning, it’s important to check for a version control system that tracks and provides changes to the source (like GIT, for example). Verify if it’s well-maintained.

Tip: Consider working according to the Gitflow Workflow, which “dictates what kind of branches to set up and how to merge them together.” Pay attention to the right names of the branches. If your product is particularly vast, consider using appropriate Git tags. It makes managing a larger project infinitely easier.

a) Technology choices

The point of this section is to verify if the tech stack is the optimal choice for the project and if it’s internally compatible. 

When you start verifying the technology choices, the first step should be to check if all applications used are named according to the LTS version and if they are up-to-date.

Then, it’s time to judge if all the components are well-tested and if they fit each other.

What does it mean in practice? For example, Django apps go together with Postgres much more often than with other database engines, like MySQL. While the less popular choices are not necessarily technologically weaker, opting for them will drastically reduce your opportunities to find help with any potential problems.

Such aspects are important to be taken into account in order to assess the sustainability of the project.

b) Deployment configuration

It’s always worth checking which services are used to support the application. You should pay attention to the software providing hosting services (uwsgi, gunicorn, nginx) and the hosting method (whether it’s cloud or local). 

Tip: There is no clear answer which methods are right—each hosting type has its advantages and disadvantages. Everything depends on the type of project you’re working with.

However, I sincerely recommend cloud hosting. It will not only help you save money (no need to care about the hardware, less maintenance, increased productivity), but you also gain much higher availability of the app. Most cloud providers offer over 99,99%!

The next step is to verify whether the application contains files which are responsible for the virtualization of the project.

Tip: I highly advise using Docker. It allows solving a lot of potential problems and bugs during the development stage, as the development version functions in an environment identical to the product version.

Then, it’s time to check whether the ReadMe file contains all the necessary elements:

• instructions for configuration,
• instructions for installation,
• a user’s manual,
• a manifest file (with an attached list of files),
• information on copyrights and licenses,
• contact details for the distributors and developers,
• known bugs and malfunctions,
• problem solving section,
• a changelog (for developers).

While revising your project catalog, you should check if it includes files responsible for continuous integration and deployment (CI/CD).

Tip: Well-constructed CI/CD pipelines can greatly benefit your project. They allow for a more effective way of building the program, but they also include scripts responsible for testing the application and verifying its validity during code-building.

Check the project configuration and verify if it doesn’t contain any passwords that a third person could find.

Tip: It’s advisable to keep all logins and passwords necessary to run the application in environment variables—whether in a machine on which the application runs or in the tool responsible for CI/CD.

Check if there’s an error-tracking system in place. One of the most popular ones is Sentry.

This section will look differently depending on the programming language and the packages/libs you use. 

With Python, you need to check carefully whether the code is compliant with the PEP 8 style guide and the PEP 257 docstring conventions.

The good news is, you don’t have to do it all manually. There are tools that might help you along the way.

a) Linters

• Pylama
• Flake8

b) Other standalone tools

• Pylint—a source code, bug and quality checker for Python;
• PyFlakes—another bug checker (it only checks for logical errors, not for style, but it works faster);
• Pycodestyle—checks Python code against the style conventions in PEP 8;
• Pydocstyle—checks compliance with Python docstring conventions;
• Bandit—finds common security issues in Python code;
• MyPy—static type checker for Python.

c) Code analysis and formatting tools

• Mccabe—a Python complexity checker;
• Radon—a Python tool that computes various metrics from the source code;
• Black—a Python code formatter;
• Isort—a Python utility/library to sort imports;
• Yapf—a Python formatter.

Even though the tools can greatly automate and speed up your work, it’s still worth it to analyze the code manually in order to find any potential:

• bugs,
• bottlenecks,
• performance issues,
• security vulnerabilities,
• dangers connected with maintaining the application.

Code audits can help improve your code and get rid of any existing issues.

But if upon running the code audit the list of things to improve feels too long, try getting familiar with a few good practices. While not all of them may be applied in every single team, here are a few that are worth taking into consideration:

• Every piece of code should be reviewed by at least two developers;
• Use githooks;
• Decide on one specific formatter configuration for the whole team;
• Share your knowledge! Both when it comes to technologies that you are proficient in and when it comes to tasks that you solved—it helps the team to adopt the same good practices;
• Consider asking the team members to use the same code editor—it will help with standardization.