Your code base should look like one person wrote it (even when you have a team)

A while back, I worked with a client who had no documented style guide for their code, but some very clear and obvious norms.

• Use const by default. Switch to let if the value will change.
• Always use semicolons.
• Use trailing commas with collections of objects.
• Indent with four spaces.
• Scope methods in objects, and use object shorthand values for functions.

Even though it was written down, everyone on the team followed the approach, and the code looked like a single person had written it even though multiple developers had worked on it.

Except for one guy.

You could always pick out exactly the code he’d written, because he just went cowboy and did whatever the hell he wanted.

He never used semicolons. He didn’t follow the trailing-comma convention. He used var for almost everything, except when he’d randomly use const. His indents had no consistency at all.

Very quickly, the code started to become a mess of spaghetti code.

When everyone does their own thing in a code base, it can rapidly become a mess of different conventions. That makes it harder to debug issues, harder to maintain the existing code, and harder to add new features.

Conventions make it much easier to know where to look for things, how to update things, and where to add new code.

This is why having a style guide for your code is important. It outlines “the norms” so that people don’t have to guess. And when someone deviates from them, you can point to the document and said, “read this.”

If your struggling with spaghetti code in your project, or need help setting up a style code for your code, I’d love to help! I have a lot of experience with that, and have one consulting spot left for the start of 2024.

Feel free to reach out and setup an exploratory call!