Principles of Clean Coding — Every Entry Level Developer should Follow (Part 1)

While reading the book “Clean Code — by Robert C. Martin” I made a list of some points worth sharing.

There will be Code

The author has argued that we won’t be able to build a machine that can do what we want rather than what we say. They will never be able to translate vaguely specified needs into perfectly executing programs that precisely meet the needs. Hence code will exist and there will always be code at the end. Now, here the author has made pretty clear to us that code will going to exist and we can’t skip that, so now that makes essential for us to be able to write clean code.

Bad Code & The Boy Scout Rule

We often write bad code due to several reasons like an approaching deadline, intolerant customers and many more. Programs must be written for people to read and only incidentally for machines to execute. We should spend a considerable amount of time thinking what we are writing and whether there’s a way to make it more clear. If we are not doing that, then it’s our fault and we are being unprofessional here. The only way to go fast is to keep the code as clean as possible at all times.

Using Intention-revealing Names

Choosing a good name takes time but saves a lot more than it takes. The name of a variable, function or class should tell you why it exists, what it does and how it is used.

Avoiding Disinformation

Programmers must avoid leaving false clues that obscure the meaning of code. Do not refer to a grouping of accounts as an accountList unless it’s actually a list. If the container holding the accounts is not actually a List, it may lead to false conclusions. So accountGroup or bunchOfAccounts or just plain accounts would be better.

Picking One Word per Concept

We should choose one word for one abstract concept and should stick with it. For instance it will be confusing if we have fetch, retrieve and get as equivalent method for different classes. All the three words means the same thing and hence we may get confused about which one belongs to which class. Hence it will be advisable if we stick with one among the above three words for all our classes.

Functions — Do One Thing !

We all have written functions in the past. Clean Code suggests a lot of things which we can take care of while writing a module or a function. The first and foremost thing is that our function should perform only one task i.e. it should follow Do One Thing rule. If we follow this then we can automatically achieve the next thing, i.e. to keep our function small. There are many times where we intend to make a function long. If that happens then we can investigate further and check whether it performs multiple task or not, if it does then split it into multiple separate modules performing those multiple tasks and everything will be fine !

Function Arguments

We all pass arguments to a function when there is a requirement. Do we really need to think about the number of arguments we are passing into the function. Clean Code says that an ideal number of arguments for a Function is zero (niladic). Next comes one (monadic), followed by two (dyadic). Three arguments (triadic) should be avoided where possible. More than three (polyadic) require very special justification — and shouldn’t be used anyway.

Signing Off

These were the few concepts which I wanted to share. So long, I find Clean Code to be an amazing guide and we all can take a page from it ! If you’re a college student and aspire to be a Software Engineer in future then these concepts may help you a lot in your future job. You all ready aim to optimise, this will make you clean as well.

Web Solutions Engineer @Google | A Pragmatic Programmer https://github.com/SauravP97