This video delves into the subjective idea of writing clean code. From experiencing similar problems in my own career, it’s good to shed a light on some things that could potentially help your own team so that the code you work with is consistent and easily interpreted going forward.

Writing clean code is a benefit both to you and your co-workers. Why? Can you remember a time when you carried out a code review and had to question what was happening in a specific function. If you have, then it means the code probably could’ve been cleaner. It’s something we should aspire to do.

To quote Robert C. Martin, “…Clean code reads like well-written prose. Clean code never obscures the designer’s intent but rather is full of crisp abstractions and straightforward lines of control.”
To start, let’s begin by asking what isn’t clean code? Our examples will be based around JavaScript.

Magic numbers – Assigning a number that has no clear meaning. It’s better to replace with a named constant.

Deep nesting – If your code contains many nested loops or conditional statements, then this should probably be extracted into a separate function.

Avoid large functions – A function or even a class that is large in size suggests that it’s doing more than it should.
Code repetition – If you have to copy and paste a block of code, it’s a sign that that the repeated block may need to be extracted into its own function.

Complex expressions – A function that is carrying out some computation, but it’s unclear what’s being computed.

So what are some of the things you can start doing to make it easier for you and your team? Let’s start with simple naming conventions.

A variable name should be intention-revealing. If you want to store a count of eggs don’t create a variable called ‘EC’, use something meaningful, such as ‘egg count’.
A function should be a verb or a verb phrase, and must communicate its intent. A shortened method name causes more hassle than the keystrokes you save in the long run.
If you need to pass a huge list of arguments into a function, use a single object parameter instead. It’s advised to have no more than two or three arguments.

To make it more natural when reading the source code, organise your script with higher level functions at the top and lower level functions beneath, making it more natural to read through.
Agree on a coding standard in your team so that every script written is consistently formatted. Airbnb and Google have a coding standard they favor with ESLint. Following these rules will save a lot of debate, and even if your team all agree on a convention, such as replacing indentation from 2 to 4, this can be overridden in the configuration.

Although subjective, the use of comments in your code can be helpful, but could be a sign your code is failing to be self explanatory.

To summarise, there are huge benefits to following these rules in the long run. Others may pick up the code you’ve written in a few days, months or even years, scan from top to bottom, and either sigh of relief or frustration. Which one would you prefer?

Original source