When a group of people starts working on a very large and important project, it is inevitable to encounter different methods of thinking and writing the code. The risk of having the code difficult to maintain is very high. We decided to study (YES, you need to study to improve processes and write clean code) and understand what was the best approach to be used internally to leave the freedom to interpret the code but maintain a clean and maintainable code base.

What is clean code?

Clean code is a consistent style shared by the programming group that simplifies writing, reading, and code maintenance. It is not enough that the code works for accepting a pull request (obviously with the necessary exceptions) but you have to ask yourself before doing the pull request:

have I removed all the zombie code? Will anyone else be able to understand this code in six months? Is it necessary a refactoring that I can not do for reasons of time / information and I have to declare it?

In simpler terms, write code that you would be proud to take home and show your mother.

Clean code is self-commenting

How many times have you really commented on your code? Or how many times have you commented on it and then changed it without even remembering to change the comment? the solution is simple and immediate. Write self-commenting code. It is fundamental to give the right name to things.

Boolean variables, or functions that return a boolean value, should start with “is,” “has” or “should.”

Functions must be as small as possible. If your function is getting too long and complex or you can not give a unique name because it does too many things, it is 99% decomposable in sub functions that perform a specific operation. Disassembling into individual functions also increases the ease of testing them and also reduces the possibility of errors.

Functions should be named for what they do, not how they do it.

Event function should have the name of the event or contain it if you have more than one event function (ex. onClick)

Example of clean and bad naming code

Another way to automatically comment on the ReactJS code is to declare the types of props used in order to make anyone who uses our component understand which props are necessary to operate and all those used. In addition, using the props-types, warnings will be printed when props don’t match with the declaration,this will help us to understand what we have wrong

Example of how use propTypes

Clean code is DRY

Dry or Don’t repeat yourself is Single Point of Truth and is a design and development principle according to which every form of repetition and logical redundancy in the implementation of a software system should be avoided. Design everything as components and use components to avoid duplicating code

Example of DRY components structure

Clean code have default values

Default values help you manage the exceptions by writing less control code and leaving more room to logical code. There are many ways to manage the default values, depending on the situations we use either the ES6 syntax or the defaultProps

Example of defaults value

Clean code is small and declarative

ES6 introduced the concept of destructuring, which really is your best friend. Destructuring allows you to “pull apart” properties of an object or elements of an array and allows you to refer to the props in a simpler and more direct way.

Destructuring example

Clean code respect a logic

This is the broadest and most difficult point. What do we mean by logic? By logic, we mean any thought to divide and manage our js code, whether by type, by membership or other. As regards ReactJS and therefore for its components, the most natural and useful way is to respect the react life cycle. But, what about the other class function or variables? The important thing is to organize them all in the same place, do you want to declare them before the constructor? Good. Do you want to declare them before the render? Well the same. I personally prefer to declare all the functions before the render and before the constructor only the declaration of the initial state. Render should be the last function since it is,almost surely, the largest one.

ReactJS Lifecycle class order

Clean code avoid side effects

In JavaScript, primitives are passed by value and objects/arrays are passed by reference. This subtle difference can make you lose hours of debugging. In ReactJS the this.state is and need to be immutable (you should change it only using the setState). It is, therefore, necessary to take precautions when we change the state before doing the setState.

Example of state immutability

Clean code is isolable and testable

Each component must be able to be used alone and can be tested independently. In caffeina each component is developed isolated using Storybook as a debugging and presentation tool, also thanks to the integration with Jest the union of these two tools allows us to test each of our components and to keep an eye on possible regressions. This type of approach in addition to making us sleep more serene has been useful many times in the course of very large projects in which we could ( 🤷 make mistakes 🤷‍♂️ ) have a base of isolated and tested components to use in different verticals

Conclusion (Clean code does not depend on the platform)

Caffeina wants to maintain a free approach to programming and clean code. Every point of our clean code is reusable in any other javascript framework, in any code written in pure javascript and in any other programming language. Our goal is not to standardize the way we write code but to give the tools to anyone who works with us (both colleagues and colleagues who will come) to be able to read the code of our projects without too much difficulty and to write maintainable code for the next months. The use of lint and automatic tests in our CI, even if necessary to keep huge projects clean, can never replace the code written with a clean code approach even if we all know what the real method of measuring the quality of the code is WTFs/minute