Clean Code Rules: The 4 Pillars & Core Principles for Developers

Clean Code Rules for Developers But why ? Have you ever gone back to a project you worked on weeks ago and stared at your own code, completely lost? I have and it’s frustrating! That’s exactly when I realized the importance of Clean Code.

To avoid these headaches, we need to write code that’s simple, clear, and expressive so it’s easy to read, understand, and maintain, even weeks or months later.

What is Clean Code ?

Clean Code is a computer code that is easy to Read, Maintain, and Understand. As human beings, we are acceptable to others when we are simple and expressive to others. Similarly, our code should be simple, concise, and expressive.

However, Clean code is more than just aesthetically pleasing formatting. Clean code reduces the chances of bugs, improves collaboration among developers, and ultimately leads to a more sustainable codebase

The 4 pillars of Clean Code

Clean Code is about making code clear, easy to maintain, test, and scale.
It focuses on readability, maintainability, testability, and scalability, ensuring your code is easy to understand and grow without complications.

1. Readability
   Code should be written in a way that is easy for others (or your future self) to read.
   Meaningful variable names, consistent formatting, and well organised code contribute to readability.

// Not-so-clean code
const a = b * 5 + c / 10;

// Clean code
const totalCost = itemPrice * quantity + shippingCost;

2. Maintainability
   A clean codebase is easy to maintain. This involves modularising your code, minimising dependencies, and adhering to design principles like SOLID.

// Not-so-clean code

function processData(input) {  
  let result;  
  // lots of code  
  // more code  
  // even more code  
  return result;  
}

// Clean code

function processData(input) {  
  return input.filter(item => item.isActive).map(item => item.value);  
}

3. Testability
   Clean code is inherently testable. It encourages the use of unit tests, making it easier to identify and fix issues.

// Untestable code

function fetchData() {  
  return fetch('https://api.example.com/data')  
    .then(response => response.json())  
    .then(data => data);  
}

// Testable code

function fetchData() {  
  return Promise.resolve({ data: 'sample data' });  // Returns mock data for testing  
}

4. Scalability
   As your project grows, clean code scales with it. It accommodates changes and additions without causing a cascade of issues.

// Not scalable code

if (userType === 'admin') {  
  // Admin specific actions  
} else if (userType === 'guest') {  
  // Guest specific actions  
} else {  
  // Default actions  
}

// Scalable code

function handleUserType(userType) {  
  const actions = {  
    admin: () => { /* Admin specific actions */ },  
    guest: () => { /* Guest specific actions */ },  
    default: () => { /* Default actions */ },  
  };  
  (actions[userType] || actions.default)();  
}

Exploring the limits

While clean code is a noble pursuit, are there limits to how clean we can make our JavaScript? In some cases, striving for perfection can lead to over-engineering, where simplicity is sacrificed in the name of cleanliness. Let’s explore a few scenarios where maintaining cleanliness might seem challenging.

1. Performance vs. Readability
   One common dilemma is the trade-off between performance and readability. For example, inline code might be more performant, but it sacrifices readability.

// Less readable but potentially more performant
for (let i = 0; i < arr.length; i++) arr[i] = arr[i] * 2;

// More readable but potentially less performant
arr = arr.map(item => item * 2);

The key is to strike a balance based on the context. Always favor readability unless performance is a critical concern. In most cases, clear, maintainable code will save you time and reduce errors in the long run.

However, when performance is paramount, optimizing for speed should take precedence but only when absolutely necessary.

2. Over-Engineering
   Over-engineering occurs when developers add unnecessary complexity to their code. This can lead to bloated codebases that are hard to maintain.

// Over-engineered solution

class StringHelper {
  static concatenate(str1, str2) {
    return str1 + str2;
  }
  static reverse(str) {
    return str.split('').reverse().join('');
  }
}

const result = StringHelper.reverse(StringHelper.concatenate('Hello', 'World'));

Simplicity is often the best approach. Only introduce complexity when it’s justified. let’s see one more:

// Over-engineered code to calculate the sum of an array of numbers

function calculateSum(arr) {  
  if (Array.isArray(arr)) {  
    let sum = 0;  
    for (let i = 0; i < arr.length; i++) {  
      if (!isNaN(arr[i])) {  
        const num = Number(arr[i]);  
        sum += num;  
      }  
    }  
    return sum;  
  } else {  
    throw new Error('Input is not an array');  
  }  
}  

// Usage  
const numbers = [1, 2, 3, 4, 5];  
const sum = calculateSum(numbers);  
console.log(sum);  // Outputs 15  

3. Premature Optimization
   Premature optimization means trying to improve performance before identifying actual bottlenecks.
   This can lead to unnecessary complexity. It’s better to first write clean, maintainable code and optimize only when real issues are found. Early optimization often results in convoluted code that’s harder to debug and maintain.

// Prematurely optimized code for finding the maximum number in an array

function findMax(arr) {  
  let max = arr[0];  
  const length = arr.length;  // Store the length of the array  
  for (let i = 1; i < length; i++) {  
    if (arr[i] > max) {  
      max = arr[i];  
    }  
  }  
  return max;  
}  

// Usage  
const numbers = [1, 2, 3, 4, 5];  
const result = findMax(numbers);  
console.log(result);  // Outputs 5  

They Say Clean Code is SUBJECTIVE

What counts as clean code rules can vary between developers, as what seems clear to me might not be as straightforward to you, and vice versa. Additionally, achieving 100% clean code may be unrealistic, especially in larger projects.

Take Pure Functions as an example: these are functions that always produce the same output for the same input, making them predictable and easier to test.

function sayGreeting(name) {
return `Hello ${name}`;
}

A pure function shouldn’t have any side effects to change the expected output. Is it a pure function?

let greeting = "Hello";
function sayGreeting(name) {
return `${greeting} ${name}`;
}

Well, no. The function’s output now depends on an external state called greeting. What happens if someone changes the value of the greeting variable to “Hello”? It will alter the output of the sayGreeting() function.

So, can you make all functions pure functions?

Yes, technically you can. However, an application made entirely of pure functions might not accomplish much.
Most applications involve side effects such as HTTP requests, logging to the console, and I/O operations.

It’s best to use pure functions wherever possible and isolate impure functions (those with side effects)
as much as possible. This approach significantly improves your program’s readability, debuggability, and testability.

Conclusion

Clean Code Rules JavaScript code is not some abstract ideal, but a practical approach to writing code that is both sustainable and efficient. By embracing principles like readability, maintainability, testability, and scalability, developers can effectively navigate the challenges of writing clean code.

While there may be moments when the pursuit of cleanliness clashes with other priorities, understanding the context and finding a balance is essential.

Ultimately, the quest for clean code rules JavaScript code is an ongoing journey one that requires constant reflection, learning, and adaptation. As we explore its limits and question its true nature, we pave the way for codebases that not only function well but also thrive in the ever-evolving landscape of web development.