Clean Code (2): Stability

TABLE OF CONTENTS

• Introduction
• What is Stability in Clean Code
• Why You Should Write A Stable Code
• Unstable Code + Effect
• Improving Unstable Code
• How To Achieve Stability
• Conclusion

Introduction

Some weeks ago, I started writing about clean code.

This is the second episode of my clean code series, in the first part, I talk about correctness in clean code.

Today, I will be discussing code stability.

What Is Stability in Clean Code

Stability has different literal definition.

Who you ask would determine what type of definition you will get.

However, if you study these answers well, you will realized they are all referring to the same fact.

Today and here, I will give you some definitions which would give you basic understanding of what stability is:

1. Stability is when a code is being tested under different valid inputs, scenarios yet still produce correct output.

2. Stability occurs when you have no need to modify your code anymore.

3. Stability occurs when your code is free from both major and minor bugs.

You probably have got to a software download page where you are given the option to download either the latest (beta) version or a stable version.

The beta version works but doesn't have the assurance that you will always get the right performance.

However, the stable version has undergone series of tests, modifications and improvements thus is guaranteed of performing well under different circumstances.

Why You Should Write A Stable Code

Just like I have explained above, a stable software is more reliable, likewise a stable code.

If you are looking for practical example or reason why you should write stable code, here is one:

Unstable Code + Effect

Unstable Code

const balance = "234"
const amountToTransfer = "1000"
if(balance < amountToTransfer){
  console.log("Insufficient balance")
  // return and do not perform transaction
}else{
  console.log("Transfer made")
  // perform transaction
}

Effects Of Unstable Code

Judging from the apparent view of the code, nothing seems wrong.

We are comparing these two variables and executing tasks based on the result of the evaluation.

However, upon running the code, we found out that the code is not executing the way we had expected.

This could cause financial audit problem, given the fact that the "amountToTransfer" could be more than this.

The "balance" is obviously smaller than the "amountToTransfer" but the code isn't interpreting this correctly.

Yeah.

The issue is with our data type.

We are comparing strings not numbers.

If you are comparing strings directly in place of number, JavaScript do not convert them to number implicitly.

JavaScript treats each number in the variables as a character and finds its equivalence in the unicode character table.

After comparing there equivalence unicode value, JavaScript returns false for the evaluation thus, running the false block of the if/else control system.

Improving Unstable Code

const balance = parseInt("234")
const amountToTransfer = parseInt("1000") 

if(balance < amountToTransfer){
  console.log("Insufficient balance")
}else{
  console.log("Transfer made")
}

Explanation: After testing our code and finding out the instability there in, we have decided to convert both variable explicitly to integer before comparing them.

However, you should also make sure from the start that your "balance" or "amountToTransfer" will always be in integer".

Also, we all know that bank do charge in "kobo" in Nigeria, "cent" in US and some other non-integer value in your country.

You will have to go with the correct data type for each variable before using it, might be float, double etc...

How To Achieve Stability

The process is simple, but may not be easy to accomplish.

TEST.

When you are done with development, test your code, get a group of beta testers and get feedback from them.

After the feedback, test again. Always test.

Conclusion

Stability is an important part of clean code, it ensures that your code is working correctly given different input or experiencing different cases.

Thanks for reading through, hope you learnt one or two thing.

I will like to hear your opinions on this...