What is Clean Code?

Clean Code is a book written by Robert Cecil Martin is an American software engineer, also known as "Uncle Bob". He’s a software consultant, speaker and fierce advocate of agile methodologies as well as TDD.

Clean code is a code that is easy to read, like a book where each word transforms into a picture and you can actually visualize everything like watching a movie, in short, should be readable by Humans.

What Is That Book About?

The book is one of the most important that exists for anyone who wants to be a good software developer. It has a lot of fantastic recommendations and is highly recommended for anyone who wants to improve their development skills.

Clean Code offers a set of very simple guidelines to help us improve the quality of our codebases little by little. I am going to select some of the ideas in it.

Universal principles to follow:

These principles establish practices that lend to developing software with considerations for maintaining and extending as the project grows. Adopting these practices can also contribute to avoiding code smells, refactoring code, and Agile or Adaptive software development.

• Follow standard rules: experiments always end in disaster.
• Avoid duplication in the code (DRY principle or Don’t Repeat Yourself ).
• We must apply The Boy Scouts rule to our profession: Leave the campground cleaner than you found it.
• Follow SOLID principles to write clean classes and well-organized APIs.

SOLID stands for:

1. S - Single-responsiblity Principle
2. O - Open-closed Principle
3. L - Liskov Substitution Principle
4. I - Interface Segregation Principle
5. D - Dependency Inversion Principle

Names rules:

The name of a variable, function, or class, should answer all the big questions. It should tell you why it exists, what it does, and how it is used. If a name requires a comment, then the name does not reveal its intent.

• Use names that can be pronounced well.
• Choose descriptive and clear names.
• Use searchable names.
• Make it easy to remember them.
• Use names according to the context.
• Use searchable names
• Classes and objects should have noun or noun phrase names .A class name should not be a verb.
• Methods should have verb or verb phrase names.

Functions rules:

The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that

• Focused, each function, classes exhibits one responsibility that they have which remains completely independent off the surrounding classes/functions.
• They should be short and only do one thing. If your function is doing more than “one thing,” it is a perfect moment to extract to another function.
• Avoid passing booleans. Why do you need to pass a Boolean? Do you need to do more than one thing within a function?
• Keep the number of arguments as low as possible.
• Dyadic Functions: A function with two arguments is harder to understand than a monadic function.
• When a function seems to need more than two or three arguments, it is likely that some of those arguments ought to be wrapped into a class of their own. 
• Avoid side effects. Declare the arguments as final(Java) if you can.
• Functions should either answer something or do something, but not both.
• Prefer Exceptions to return error codes and extract error handling try catch into their function.
• Don’t return a null value. What is null? It does not provide any information.

Formatting:

First of all, let’s be clear. Code formatting is important. It is too important to ignore and it is too important to treat religiously. Code formatting is about communication, and communication is the professional developer’s first order of business.

• Avoid too-long files.
• Good files have a heading, the critical stuff first, and details later.
• Although we now have big screens and with high resolution, avoid lines get too long (80 or 120 is perfect, in my case 100). You will get used to being more concise, and your code will be more readable.
• Be consistent with the rules of your team.

Classes:

A class should begin with a list of variables. Public static constants, if any, should come first. Then private static variables, followed by private instance variables. There is seldom a good reason to have a public variable.

• Classes should be small.
• You should declare local variables as close as you can to their usage.
• You should declare instance variables at the top of the class.
• Constants should be declared at the top of the class or in a Constants class by example.

Objects and Data Structures:

The difference between objects and data structures: Objects hide their data behind abstractions and expose functions that operate on that data. Data structure expose their data and have no meaningful functions.

Procedural code (code using data structures) makes it easy to add new functions without changing the existing data structures. OO code, on the other hand, makes it easy to add new classes without changing existing functions.

• Hide internal structure.
• If you can, call only your methods of your class, of objects you have created, and avoid call methods reachable through these objects (Law of Demeter).
• Follow the Law of Demeter: A class should know only its direct dependencies.
• Improve the decoupling of objects.
• Variables should be private and manipulated by getters and setters, but remember, there is no necessity to add getters/setters to each variable to expose them as public.
• The base class should know nothing about their derivatives.
• Objects expose behavior and hide data. Conversely, data structures expose data and lacks of (significant) behavior.

Error Handling

Write Your Try-Catch-Finally Statement First

One of the most interesting things about exceptions is that they define a scope within your program. When you execute code in the try portion of a try-catch-finally statement, you are stating that execution can abort at any point and then resume at the catch.

Today, we learned…

• What is clean code? and various factors involved to make your code clean.
• Some coding best practices and rules that the uncle bob recommended to help improve the quality of software.

We end this article here, but there’s so much more.This is just the beginning of clean code, I will be writing more stories explaining you how to write clean code in greater details.

Thanks for reading !