The Pursuit Of Clean Code

There are different ways to interpret the meaning of clean code. The idea of clean code is a subjective concept and every developer has their own interpretation of it.

Clean code is code that is easy to understand and easy to change" 

When we say "easy to understand" what does it really translate to? Easy to understand can be easy to read, it can be easy to understand the flow of the code, easy to understand sequence events. Easy to understand can also quantify to the ease to understand the purpose and function of the methods and variables defined or declared. Easy to change can be interpreted as easy to extend and refactor, and it is easy to fix bugs. Easy to understand can be anything! it's up to the readers interpretation.

When we write code it is generally in as higher-order language. This implies that we intend the code to be understood by other developers or other people. A higher-level language is not directly interpreted by the computer. A high-level language is compiled or interpreted into an assembly level language or a binary. The reason high-level languages exist is that they are easier to read, write, and maintain.

Programming is the art of telling another human what one wants the computer to do.

- Donald Knuth 

Clean code is not just writing code that is good or easy on the eye. Efficiency in the execution of the code is also a vital aspect of composing clean code. Efficiency can be correlated to the time it takes to execute a block of code. an example of bad and inefficient code would be:

function IsNumeric(sText) {
    var ValidChars = "0123456789.";
    var IsNumber = true;
    var Char;
    for (i = 0; i < sText.length && IsNumber == true; i++) {
        Char = sText.charAt(i);
        if (ValidChars.indexOf(Char) == -1) {
            IsNumber = false;
        }
    }
    return IsNumber;
}

This can be written with a simple implementation of isNAN().

Over the past few years, I have made some observations that guided me in the path to writing clean legible code.

1. Rules for naming
1. select descriptive and unambiguous names.
2. use pronounceable names.
3. Magic numbers.
   
4. use the correct case.
1. camel case
2. snake case
3. kabab case
4. pascal case.. and many more.
   Each type of casing of text implies a specific meaning to the code.
2. Function rules
1. keep the functions small.
2. do one thing and one thing only!
3. verbs as function names. Because functions always perform an action it makes sense to name them with verbs.
3. Comments Rule
1. don't add obvious comments.
2. try to express your intent in the comments. don't explain unrelated facts about the requirement.
3. use comments to highlight warnings.
4. try to express yourself in code and not in comments. Most programming languages are high-level languages, meant for humans to understand.

So Why do we strive to write clean code? cant we just go with code that just works? there are many reasons for writing clean code:

• Easier onboarding of team members. If you are working with rotating teams, a common outcome for most development teams within the pandemic. It is best if it takes less time to onboard new team members.
• Easier debugging. When it is easy to read and understand the codebase it is easy to pinpoint the segment of the code where the error or bug is occurring.
• better utilization of developer's time. The developer reading the code is not trying to figure out how the code works but is either implementing new features or refactoring the code.

Another aspect that comes up every time there is a discussion of clean/bad code is complexity. The causes of complexity are not always directly attributed to bad code, in much the same way that bad code is not always the direct result of bad or even poorly skilled developers. even senior developers write complex, difficult to understand code. Many believe that complexity is caused by two things: Dependencies and lack of clarity. 

Dependencies can be both external modules/packages and developers who wrote some parts of code. If there is an excessive dependency on an external module the team is forced to write code as dictated by that module.

 the other form of dependency is what I call "Key Person dependency". This is when there is an over-reliance on one developer to write and maintain most parts of the codebase. Both forms of dependencies are caused by a given piece of code that cannot be understood and modified in isolation: the code relates in some way to other code and the other code must be considered and/or modified if the given code is changed.

The bottom line is that writing clean code has visible benefits. It improves the standard of code which directly affects the maintainability of the software or applications. The complexity of a codebase is heavily driven by dependencies and incremental changes, both in the team and in features. The development teams must spend quality time to write clean code. At its core, clean code is about eliminating complexities and improving the readability of the codebase.