In Coding, Nothing is Trivial

 

Imagine you're reviewing some code, as part of a Pull Request, and the developer has misspelt a variable. Or added a magic string instead of a constant. Or put the expected/actual parameters in an assertion the wrong way around (although it kinda doesn't matter because they're the same)?

You can politely comment on it, and perhaps they will fix it up. But sometimes you might be met with resistance. 

"It's not that important."

To a degree, they're right. These are pretty trivial observations. There are probably bigger things to address, such as the logic, the architecture, the test coverage etc. 

However, in coding, these trivial issues tend to come back to bite you, either as bugs, or as maintenance headaches.

You don't want to nag people. You don't want to become a "clean code nazi". But you can firmly assert that you think a mistake is being made and that a potential issue could arise. 

There are some things in coding that are a personal preference. There are some things that are virtually (though not completely) insignificant and which you should avoid fighting about (tabs vs spaces) and then there are things which actually matter. The lines are blurred and you should always be pragmatic - but the things which actually matter can be proven to matter - a misnamed variable can cause confusion, expected/actual parameters the wrong way around can lead to false positives in your tests, and magic strings can lead to runtime errors, code duplication, and mysterious bugs that can really mess up your day.

What's important is that you communicate these issues when making your suggestions. Make it clear that this isn't a personal preference thing - it's not you being fussy, but that it could lead to genuine problems. 

The main reason that many of these "trivial" issues can lead to serious problems is maintainability - other developers working on the code.  Maintainability is just so important - not having it leads to bugs, slow development, demoralised developers and more. Anything that affects maintainability, isn't trivial. Its effects are amplified because of all the people that become involved in the problem.

When you have maintainability problems, you get bugs. It doesn't take much to turn a badly named variable into a half day investigation and a costly Production change.

So, raise your standards. Don't settle for "It's not that important". If you have an issue with it, if it niggles at your brain even slightly, it's for a good reason. Your subconcious can spot a time bomb. Trust it.

Popular posts from this blog

Ways to Spot Single Responsibility Violations

Clean coding Tips: Access Modifiers

Hololens: What Kind of Applications Can We Build?