In the previous posts, we discussed two important issues regarding project development. The first went into the differences between monorepo and multirepo, and the second explained the motivations behind common and separated dependency versions.
Today, we will examine two types of code checking tools that help ensure the quality within our codebase. One is related to a language type system, and the other to a visual preference of code syntax. Regardless of the category, in general, static code verification happens after we write the code and before we execute it. That’s why it is a great space to improve various aspects of our implementation.
Static type checking
Let’s start with types and their verification system. They are usually built into specific programming languages, like TypeScript. In short, we write our logic using a more sophisticated syntax that includes type declarations. Afterward, we trigger the compiler to inform us whether all those declarations match the implementation.
We can imagine those types as a meta layer that operates next to the executable code layer. When we cross those two levels of logic, we can automatically catch errors ahead of time during the compilation phase. It is worth mentioning that some of those errors could not be spotted on a single layer alone.
The advantages seem pretty obvious because we are almost free of runtime errors if the types are strict and correct. Our code feels safer, almost double-checked. As a result, we do not need certain unit tests because meta declarations verify and block unintended paths.
In addition, we may appreciate the documentation value of type declarations. Sometimes, it means that the code can better explain itself without the involvement of in-code comments.
As the main drawback of having static type checking, we can point out the development time. When comparing line to line implementation speed, type declarations cost more, especially when we aim to do it right. However, it is not true when we compare big projects with years of history. In that case, considering a broader period, static type checking pays off immensely.
In summary, we should pick this tool to ensure code quality, and the more strict rules we set, the better. Even if that leads to higher task estimations, it is a profitable long-term investment.
Besides strict language rules configuration, one thing to keep in mind is to write type declarations as precisely as possible. That is because the more optional properties we define and the more untyped loose ends we leave, the less we benefit from the work of the compiler.
Static code analysis
Here, we will discuss code linters and formatters. They are quite similar, and many tools provide both functionalities in a single script, yet they usually work differently, and we expect them to help us in various ways.
Linters should help us fix specific syntax mistakes and ensure we do the right thing regarding the language preferences. Formatters, on the other hand, take our entire code and present it in a consistent pre-defined style.
For the sake of this article, we will treat them as brothers in arms and describe their pros and cons as one.
There are two major advantages in using the static code analysis with automatic formatter. The first one circles around the idea that the code we write is read many times by various people. That’s why we should help them to understand what they see. When every syntax, everywhere in the repository, looks exactly the same, after a while, the programmers will focus on the substance more, without any unnecessary distractions. It is amazing how a weird kind of indentation may steal our focus.
Another thing is connected to code reviews and other kinds of human code analysis. When we ensure that every piece of submitted implementation has only one valid visual form, then we may completely forget about reformat commits and thus issues related to comparing historical changes.
That is a truly great benefit for future generations.
There is some drawback regarding the subject, yet I do not believe it is significant. Everybody has a little bit of individualism in them and a personal preference. Programmers tend to be especially attached to their code formatting habits.
Well, there is a chance that somebody has a better style than the automatic formatter suggests. Sometimes, our configuration possibilities are limited, and we know the linter is wrong. However, it is not essential from the project perspective. Truth be told, it is better to have a mediocre but consistent style than allow for inconsistencies, especially when we talk about many teams working on a large project.
Conclusion
It is true that not every tool is necessary for every project. I wouldn’t recommend huge overhead for a small proof of concept. Nevertheless, when we discuss big projects developed by many teams for a considerable number of years, the benefits for the future may be tremendous if only we spend some time on quality now. Cheers!