Clean Code

29 Nov 2020

While wondering about what I should write for my first ever tech blog, I figured why not go to the basics and apply the same principle here. So here I am talking about Clean Code and summarizing my learnings from Clean Code by Uncle Bob

So what is clean code?

Any code which is easy to understand, debug and maintain is clean code. The only valid measurement of code quality is number of wtfs/minute. As per Bjarne Stroustrup: "I like my code to be elegant and efficient. The logic should be straightforward to make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy and performance close to optimal so as not to tempt people to make code messy by making unprinciples optimization. Clean code does one thing well."

Let's look at some of the guidelines for writing clean code.

Meaningful Names

• Use intention revealing names.
• Avoid disinformation. Programmers must avoid leaving false clues that obscure the meaning of the code.
• Spelling similar concepts similarly is information. Using inconsistent spellings is disinformation.
• Make meaningful distinctions. Distinguish names in suchh a way that the reader knows what the differences are. Use searchable names/
• The length of a name should correspond to the size of it's scope.
• Avoid using puns, encodings and mental mapping. Class names should be nouns and method names should be verb.

Functions

• The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.
• Blocks within if,else, while statements should be one line long. This also implies functions should not be large enough to hold nested structures..
• Functions should do one thing. They should do it well. They should do it only.
• Describe the function by describing it as a brief to a paragraph. Functions that do one thing cannot be reasonably divided into sections.
• The ideal number of arguments for a function is zero; followed by one and two. Don't pass a boolean into a function, it's a terrible practice.
• Functions should either do something or answer something, but not both. Either your function should change the state of an object, or it should return some information about that object.

Comments and Formatting

• Don't comment bad code, re-write it.
• Comments don't make up for bad code. The proper use of comments is to compensate for our failure to express ourself in code.
• Information, explanation of intent, clarification, warning could be described by comments.
• Code formatting is about communication; and communication is the professional developer's first order of business.
• Concepts that are closely related should belong to a single file.

Objects, Data Structures and Classes

We don't want to expose the details of our data. Rather we want to express our data in abstract terms. Objects hide their data behind abstractions and expose functions that operate on that data. Keep your classes small in terms of responsibilities. Single responsibility principle states that a class or module should have one, and only one reason to change. Have many, but smaller classes.

Error handling, Unit tests, Et. Al

Always use exceptions rather than error codes. Try to write tests that force exceptions and then add behaviours to your handler to satisfy your tests. You many not write production code until you have written a failing unit test. Test code is just as important as production code. And always have single concept per test. Your tests should be fast, independent, repeatble and self-validating.

Classes

• Classes should be small in terms of responsibilities.
• Single responsibility Principle states that a class or module should have one and only one reason to change.
• Use Open-Closed Principle, Dependency-Inversion Principle.Classses should have a small number of instance variables, each method of class should manipulate one or more of those variables.

This is in no way an exhaustive list, but I hope this will act as a good starting point on how to write clean code. Always remember to keep things simple, complexity kills - it sucks the life out of developers, it makes products difficult to plan,build and test. A design must produce a system that acts as intended. Code should clearly express the intent of it's author. A design is simple if it follows the below rules:

• Runs all the tests.
• Contains no duplication.
• Expresses the intent of the programmer.
• Minimizes the number of classes and methods.

Happy Coding!!