Written by Brightec Team
Oct 13, 2014

Code Standards

What’s the difference between code standards and code style?

Code standards and code style

What’s the difference between code standards and code style? I would suggest that code style is more superficial than standards; your code isn’t going to break or be less functional if a tab is out of place.  

Standards are a little more serious. It’s about ensuring that quality doesn’t suffer as a team grows, or is placed under pressure. This post continues our series ‘evolving the dev process’ which discusses how to implement standards and tools which help grow a team effectively.  

This post is about code standards and is a continuation from Evolving the dev process : Part 2 Code Style expectations.

Pair programming

There are a few tools to ensure code standards. However, it is difficult to automate and needs senior eyes; the lead developer needs to steer the boat.

Pair programming is great, but in reality there is rarely time for this and it’s tricky to get integrated regularly as part of the dev process. Management are often reluctant to lose a resource (developer) to a single problem that would normally take one developer. When I’ve experienced pair programming, it’s usually been a one off between two seniors who are tackling complex problems together.  

However, I do believe this is a good training tool and should be a regular part of a team's tool kit.

Code Review

Often a great trigger for pair programming is a code review. 

We’ve recently integrated code review as part of our kanban process: once a developer deems their work complete it is marked ready for code review. A pull request is made and a senior developer will review the changes. Github shows a diff and the reviewer can comment on specific lines. Once requested changes have been made the code will be merged and marked ready for testing.  

A code review should be undertaken by a senior member of staff and be focused on functionality and architecture, not code formatting - this is fixed by the methods discussed previously.

Code review is designed to eliminate poor architecture, bugs, bug prone code and most importantly it’s an extremely powerful tool for teaching. For tips on effective code review I highly recommend this article.

At first glance code review might seem like a way to criticize code and can be quite intimidating for the reviewee. However, if the lead or senior developer can articulate well why a piece of code is not suitable for the code base, this is a powerful learning tool. 

My best lessons and progression as a developer have been because of great lead developers and their code reviewing skills.

"My best lessons and progression as a developer have been because of great lead developers and their code reviewing skills"

Developers have weaknesses

Regardless of your hiring process, all developers have a weakness.

Some developers tend to over engineer systems - writing code that is difficult to read and edit. Others tend to code in a very procedural manner. Some may miss details and focus on the happy path whilst missing exceptions. Some developers have poor UI skills and some are simply missing technical knowledge.

I realised very quickly after several reviews that my code was being returned because I had a tendency to overcomplicate things. Since then I have progressed as a developer by focusing on what could be the simplest solution first. Complexity is always the last resort. Imagine if everyone on your team made such realisations. It’s invaluable training and a continual team improvement!

Junior developers

Often a new programmer will know how to write code, but they will not know how to write good code. Using code review, juniors will quickly learn to identify bad code, it will encourage them to think in different ways.  

When hiring is tricky and you can’t get hold of more experienced developers it pays to invest in processes which enable fast training to an acceptable level of quality.  

Spotting issues early

We don’t just use code review tools for finished work. Since we can review a diff, it’s useful when a developer needs to ask “am I on the right track?”, or “I’m stuck, this is how far I got”. At this point we could review and have a conversation or alternatively start pair programming and tackle the problem together.  

The sooner in the dev process we can identify issues or get guidance from team mates that have more experience with that area of the codebase, the more development time we save upfront.  A developer who realises they were on the wrong track early on, is a developer who's saved themselves a few tears and possibly a weeks work. Fail fast, fail early.

Code review keeps us all happy - minimal time investment with huge pay offs.

Evolving the dev process

Don't miss the previous posts in this series: Why Continuous Integration? and Code Style expectations

This article was originally written for Brightec by Seren Matthews

Next Post

Branching Strategy

Previous Post

Code Style expectations