DEV Community

Sagrario Meneses
Sagrario Meneses

Posted on • Updated on • Originally published at

Importance of code standards

Standards are ever present in our lives, are the building blocks of order in an otherwise chaotic world. Software Engineering is not an exception to the rule, as a consequence, code standards are a basic requirement for quality systems.

For companies, the quality of their digital applications represents growth. If you are part of a team that do not pay attention regarding following standards, please keep reading to know the advantages of this practice.

What are code standards?

Code standards are a series of rules defined for a programming language or a specific programming style. The style ensures that all engineers who contribute to a project have a single way to style their code, resulting in a consistent code base, making certain the product is easy to read and maintain.

The use of standards is very important in the quality of software, however, keeping all projects in perfect compliance with established standards is not an easy task. It requires great effort and consistency on the part of the engineering team. While more and more companies have adopted standards, there are still those that begin the development of new projects without them.

Working without code standards

When you are part of a team that does not work with rules, it is very common to see different styles of coding in the same project, which can turn into a repository that is difficult to read and maintain. If poor organization increases, this can make us spend hours trying to fix a problem.

Not establishing rules can also lead to a hostile work environment, in which some engineers write code in their own style and others write differently. At the time of unifying the work, there are discussions to choose the best option, and by not having established rules or not having them officially validated by the entire team, the discussion can be longer than normal, causing delays in the delivery of new features.

Usually, when we create a new project we focus on getting the application to work as the first goal, this is not bad, most of the software applications have a commercial or economic purpose that must be resolved in principle, but once certain stability is reached it is important to go back to review the initial product and consider refactoring, this is in order to make the future maintenance easier.

How to introduce code standards to existing projects

"Rome was not built in a day." the adaptation must be progressive. Considering that those kinds of practices are not something a team can adopt immediately, start by trying to implement standards in new projects and then gradually establish an appropriate level of standards in existing ones.

Initially, it may be difficult for the engineering team to adapt, the contrast between not having official rules established in the code review process vs. starting to have them may be a change that not everyone accepts naturally, some will take longer than others. To reduce the adaptation time, it is important to let the whole team know the main advantages of this practice.

Not all companies use the same tools in their development and it can be complicated to find the best standards that fit with your team and codebase. But a good start to achieving quality can be documenting the standards agreed upon, the team can create a standards repository that everybody can continuously reference, review, and update.

Also, you can start by adopting official standards from the tools/languages you use. Automating certain code validation processes can be of great help for continuous integration.


  1. Use the official standards of the tools used in each project as the base.

  2. To improve code readability, pay attention to code styles like code segments, indentation, length of lines, and line spacing.

  3. Naming variables, functions etc.

  4. Establish limits in complexity or length of functions.

And most importantly, do not stop at the implementation of these rules, do not increase the technical debt in projects. Maybe today you have a very large project in which standards have never been implemented and it seems a waste to start doing it, but it is a worthwhile investment to build a quality product and also an engineering team with quality. If the implementation of these standards starts to be a real headache, it is necessary to consider a complete refactoring of your system. "Divide and conquer", it is recommended to start module by module.

Advantages of having code standards from my experience

  1. Early error detection:
    When trying to comply with the standards we established, it has been easier to detect possible errors in code reviews, preventing these problems from reaching production.

  2. Reduction of complexity:
    Complying with the rules about code style helps build cleaner code, allowing us to easily detect opportunities to simplify our functions.

  3. Easy to read code:
    Respecting the standards in our projects has allowed new team members to easily adapt to the way of work and better understanding of the code in the repositories.

  4. Reusable code:
    Thanks to the use of good practices, we have code segments that can be consumed by more than one service, reducing duplicate code.

Recommended clean code principles

It is a good strategy to familiarize the team with some principles of clean code. Below are some of the principles that can inspire an engineering team to create standards and to seek quality in the development process.

  1. DRY - Don't Repeat Yourself.
  2. YAGNI - You Aren't Gonna Need It.
  3. KISS - Keep It Simple, Stupid.
  4. SOLID
    • S - Single-Responsibility Principle.
    • O - Open-Closed Principle.
    • L - Liskov Substitution Principle.
    • I - Interface Segregation Principle.
    • D - Dependency Inversion Principle.


Keep in mind that there will always be processes to improve but it is a continuous effort and you will be able to continue working on it.

In my experience working with different engineering teams, I have seen very good results using this practice, for example:

  • A reduction between 60 and 80% of incidents.
  • Decrease in the number of hotfix deployments.
  • A significant improvement in the quality of the development team.

As we can see, the definition and use of standards provide many benefits, personally, I enjoy the work more when there is an approach towards quality code than when there are no established rules. However that cannot be achieved without the work of all engineers in a team, it is about pursuing the same goal together.

Top comments (0)