3 basic rules of Clean Code

Developers write business ideas as code. Sometimes we don't realize that our code can be clean and more readable. Clean code is the way of creating elegant, readable and testable code. Applications written according to clean code rules are easy to scale, pleasant to work with. Proper naming of variables, methods, classes as well as keeping application layers in order is very important.

Do you need a clean code?

Here is the clean code main idea: anybody who will ever read your code, will know exactly what was your intention and what code is doing. Code is explaining itself by good naming. Sounds legit, right? But why exactly? Why do we care if code is self-explanatory?

Before I answer, please ask yourself: “How much time I'm spending on writing code, and how much time I'm spending on reading code?”

If you spend most of the time coding – congratulations! Although most developers spend more time on reading code, than writing it. That is why it is crucial to be sure, that code is easy and pleasant to read. The benefit will be for example less mistakes and less stress.

Nobody writes clean code at the beginning, code is evolving and changing. That’s why it is very important to rethink what you write. Pair programming and consulting with team-mates will help you with that, thus improve quality of your work. You can take a part in creating ideal work environment, it is a continuous process which need constant improvements. Write draft of code, look at it and make it more clean. When I think about it, clean code might seems similar to sculptor’s work – shaping our masterpiece by reducing volume.

Pair programming

Working in pairs improves code quality and speed of work, it creates a possibility for two developers to share knowledge and ideas with each other. The result will be better, than a person could achieve alone, and solutions born during discussion might be way better. Pair programming looks basically like this: two coders are sitting at one desk, one person is writing a line of code, and second person is commenting on it immediately, offer with idea what can they write in easier way. Pair programming is also a nice way to share the knowledge between experienced colleagues. It's about brainstorming, boosting two different mind processes while writing and analyzing what was written.

Some clean code guidelines:

1. Less code is always better.

When it comes to writing a software, it's often that while starting and writing the very first lines of our class there might be a bit of more code, than it's needed. For example, public method in service can contain some variables which are not necessary needed, block of logic or "if" statements which should be extracted into separate method. For example, result of method can be used directly in code, creating variable and assigning a result to this variable is not mandatory.

Reduce the amount of code in one place. Remove unused variables.  Remove comments as well - code should be self-explanatory.

2. Extract method.

How long is your method?  If it has 20+ lines, many “if” statements, loops etc., then you should think about it.  Extract it to another method with a proper name that gives the impression what it's doing clearly in one glimpse of an eye without analyzing the logic. Why use method extractions? Because it helps to hold easy, to read method structure. It's always better read one method containing 20 lines calling 10 different methods, than method containing 400 lines unnamed logic and twisted commentary.

3. Good naming.

It's worth to spend some time to find proper name for a class, method, variable we are creating. It will save our colleagues a lot of time. Don't use abbreviations, names should be simple and self-explaining. For example, “usersAction” is an unclear method name – to know what it means, you have to look inside a method body. For contrary, a method with a self-explaining name could be “saveUserInDataBaseAndSendAnEmail”. This name tells exactly what method does. Inside you can expect separate methods with names: “saveUser”, “sendAnEmailAboutSavedUser”.

- Variable, name should tell what data it's holding or what service is hiding behind of it.

- Method, reading a method name. You should know exactly what it's doing, without diving into logic.

- Class, should be named according to domain (part of system logic it is responsible for, for example, domain can be payments, invoices etc.). If Class start to grow more than 200+ lines, think about dividing it.

I will stress this once again. Clean code means benefits: pleasant work, less stress, unit tests, easy debugging and better quality.

I know that if you are dealing with a messy code, working with such environment will take more time, nerves and energy than it should. It's not because you are a bad programmer, it’s simply because analyzing this code is taking a lot of time, and is (as we are only humans) frustrating and tiring. Nobody like working with badly designed code, where a bug is inevitable. There are many reasons why bad code appears in many projects, maybe this is lack of time, lack of knowledge about technology. Maybe because you just didn't know that it can be written in different way. Now, when all excuses are gone, go and reshape your code! Introduce one good practice at a time, and results will come sooner than you expect! Good luck!

Piotr Żak, Software Developer at Robert Bosch Sp. z o.o.