If someone asks me how much time we should dedicate to the creation of standards for a project, I will say “as much as we need”. Why? Because everything in our lives is standardized. The colors of the traffic lights, the ways we drive, the places we need to go in order to use public transportation and so on. And we are satisfied with it.
The main problem of the lack of standards is that everyone will do the same thing, but in a different way. And that is the recipe for disaster. For example: Sizes of clothes. We are often advised to buy clothes in the same stores or from the same brands because the sizes may differ from one store/brand to another. A shirt size “L” in the store A may fit you well, while size “L” of the same model of shirt in the store B may expose your belly.
And in software development standards are often neglected by teams because “we don’t have time for that” or “the client is not paying for standards” or even “if you need you can copy from someone else’s code”. This is a mistake because standards are the only thing that will make a group of different people coming from different backgrounds to work in a large codebase with consistence.
If you still don’t think this is a problem, think about this: There are some people who prefer to use if, for and foreach without curly braces (and people who prefer them with), there are people who don’t care about the length of the lines (those who enable word wrap) while others prefer to break it after a number of characters. Not to mention those who prefer tabs instead of spaces (or vice-versa). Just imagine how messy a file touched by all those different people in different moments of the project would look like. Tabs and spaces mixed up, inconsistence on the look of conditions, etc. What can prevent that? A simple set of rules.
If this doesn’t happen in your team, congratulations. You are lucky to work in a place where everybody codes in the same way. But I’m going to feel bad for the new employee who will join coding differently as he will be labeled as “the guy with ugly code” until he gets used to the code the team produces.
There are multiple ways to enforce code consistence, but I normally stick to a simple one: The .editorconfig file. If you are not familiar with it, the .editorconfig is a file containing the styling rules of your code. You may want to check if your editor/IDE has support for it. It’s free and the file can work in scenarios where a project has people working in multiple technologies and operating systems. Commit to your repository along with your project and everyone will code in the same way. I could also mention ReSharper, but this one is paid and specific for .NET Development.
I understand it’s boring and/or annoying to sit with the team and go over standards. I’d expect to do this just once, in the beginning, but leaving the door open to discuss some changes as the project progresses. After a while the changes will come to a minimum and you will even spread the standards across projects and teams. As it should be.
What do you think?
Top comments (0)