Consistency Matters!

Consistency in software development involves the normality between method names, interfaces, and more. Consistency issues during software development should be addressed through the arrangement of individual pieces. These arrangements can differ from system to system, as well as a software team’s preferences. In my opinion, a team’s preferences matters more than anything else; however, it should still conform to most of the style guidelines. I’ll go through some examples through this post and make consistency cases concrete with examples.

Greenfield Project

This is the almost easiest case to handle. A team should define their style guides for themselves based on well known style guidelines. These guidelines may differ from one language to another. Recommended style guidelines for popular languages are as follows:

• Java: Google Style Guide for Java
• JavaScript: JavaScript Style Guide
• Python: Pep 8
• C, C++: GNU Coding Standards
• PHP: PSR-2: Coding Style Guide
• C#: C# Coding Conventions
• Ruby: Ruby Styleguide

There are many other language style guides that could have been listed here but I preferred to keep my list short. The point is basing team’s style guide around widely accepted style guidelines. Once a team has a base, than they can update their guidelines according to their preferences. One might use IDE support to conform to coding conventions.

Legacy Project

It’s fun to start a new project but it’s not possible most of the times. So, a team might need to take over a legacy project where project doesn’t conform to well known guides. First of all, it’s almost impossible to refactor every piece of code to make it conform to well known style guide. Even if it was, it would probably take great amount of time. So, my suggestion here is to conform to existing style guide if there exists any. For example, if legacy python project has used camel case consistently instead of snake case throughout the project, I would not try to change that. Plus, I would follow that to make it consistent within the code base.

I’ll go through some easy cases:

1. Use of abbreviations
   Sometimes, one would use abbreviations lowercase instead of uppercase. You might feel like changing it but I think one can again conform to it if it’s consistently used through code base.

   public void getSql()

2. SQL mapping
   One might prefer column index over column label. Again you might want to change it but it’s easier to conform what’s already there than introducing something label index or column index.

   rs.getString(1)

3. Whitespaces
   A python project might have one line between functions although convention is to use two. If all the functions conform to one line style, than it’s ok to conform to this convention.

   def getUser(id): pass
   
   def getMap(id): pass

4. Comments
   I believe code should speak for itself so I would keep comments as little as possible. It’s unnecessary to have comments for simple methods. However, if code base has already comments for all simple methods, one should follow that style.

<?php 
/** 
* Convert an object to an array 
*
* @param object $object The object to convert 
* @return array 
* 
*/ 
function getArrayFromObject($object){ //implementation } 
?>

We could give many other examples but I want to keep it short. The point is to conform to styles that are already present within the code base.

In consequence, code consistency matters for readability and understandability. It’s an aspect a team should agree on. Changing coding style is hard so it’s better to conform to what’s already there.