Enforce Code Standards

via GIPHY

Ask a developer what they do the most while programming. You will probably get some confused looks at first, because not many developers have asked themselves. Some of the answers may be “typing” or “thinking about the problem”, but that isn’t even close.

I can guarantee that they spend most of their time just looking at the code. They are always following function calls, reading functions, interpreting logic, etc. All these things are just looking at the code and trying to understand it. If you are looking to speed up development time, the best way is to reduce the time it takes a developer to look at code.

Enforcing a set of code standards is the single best way to reduce this interpretation loop. The team can even use it as a bonding experience to come together and create their own set of standards. If that doesn’t sound appealing, adopt a mainstream one like Google’s, LLVM’s or Apple’s. The fact of the matter is that any set of standards is better than no set of standards.

Readability is the number one factor of great codebases. Any code produced should be readable regardless of the experience of a developer. Descriptive function names, variables, and tests will provide extremely valuable information to a developer as they look at the code. If a function is named “doStuff”, what on earth does it do? Well, it does stuff. What stuff? It doesn’t matter, because anyone, even the person who made it, has to go into the function and figure out what is happening. Now, what if the function was named “sortStringsAlphabetically”? Everyone who reads the function name knows that it sorts strings alphabetically.

One of the keywords in the title of this section has been implied, you have to enforce the code standards. This means the team needs to be empowered to say “this code cannot be merged because it doesn’t meet our standards”. There will be pressure from anyone higher up in management, but they hire developers because of the developer’s expertise. They trust you to do the job correctly and to the best of your abilities, so do it.

Enforcement is always the hardest part in my opinion. At all of the companies I work at, I make it my goal to say “I don’t care about my job, I care about my career”. Improving my craft as a developer is far more important than being employed by a company who wouldn’t value it. So, rather than succumbing to the pressures of deadlines, I say “any code I review will adhere to the standards we agree upon”. In the end, it is my name that will go on the code.

At previous companies, I began taking as long as I needed to make sure the code I wrote or reviewed was readable, understandable, made sense, followed the architecture, and that there were unit tests. It was easily noticeable the change in the quality of the application. Any section I worked on or reviewed had less defects and had faster turnaround times on defects that did show up. Other developers loved working in the sections I coded, and dreaded working in others. Eventually, they took my example and began doing the same thing.

You will meet lots of resistance trying to enforce standards. You will hear things like “Oh, you’re being too critical” and “this takes too long”. Keep true to your craft and your passion, and you team will reap the benefits.