Tips for a blingy-blingy code

During this crazy period, we have heard a lot about hygiene and understood that, in some cases, we underestimated its importance; but, do you know that there might be hygiene habits that you can take for your beloved software as well?

When I talk about your code hygiene measures, I don’t expect you to have a clean and bright theme on your IDE, no-no.

I’m mostly referring to readability, neat style, and attention to detail that will ease your and the other's coding experience.

I have to admit it, when I review code I tend to be pretty picky about the coding style, and in this article, I’m going to pinpoint some of the most important things I like to find when I look at a block of instructions…

Let it describes itself

One crucial thing about code is that it should speak for itself.
Think about that, you write code for (mainly) two reasons:

1) Instruct the machine to achieve a goal
2) Let yourself or others change, eventually, the instructions

The first case is covered by interpreters and compilers.
What about the second one?
The code you write should be human-readable, not machine-readable.

This means that you should always use meaningful names for files, variables, and functions.

Comments are not evil

I did find people that hated commented code, and I agree when obvious things are commented out.
Generally speaking, the code should speak by itself even though there are cases when it’s not enough, for example thinking about complex algorithms or intricated business logic.

In such a case writing 3 or 4 lines of comments is definitely better than nothing.

We might be geniuses but we never know who will come after us, and we should respect him/her.

isFlag = true

Following the “naming” convention topic, I like to prefix flags with verbs.
“isUserLoggedIn”, “hasError”, “areTasksCompleted”, etc...

Why? Because that’s how I would speak to a colleague of mine :-)
Plus, it also lets me immediately understand that I’m dealing with a boolean value. Win-win.

Make it breathe

Talking about human-readable code, the aesthetic takes an important role when we have to deal with it.

We read code as we read a book and (except in special cases) we use eyes as the main interface.

That’s why code blocks should have to be separated by empty lines and grouped by “concept”.

Crowdy files are hard to read and might have a bad impact on the developing experience, especially when in a team.

Keep it short

People that talk a lot are known to be hard to be followed in a discussion and so might be your code if you tend to use and re-use things without taking the effort to review what you just wrote and simplify it when you realize that there are too many repetitions in it especially if you are also dealing with code that is too crowdy and doesn't have pauses in it … like this paragraph :-)

So, simplify as much as you can; which is definitely harder than adding pieces to the pile. I know.

Avoid unneeded repetitions

As said before and above, avoid unneeded repetitions. They only make cognitive noise.

If something has been written twice, put it in common (and consider it a util or a helper).

Align it

We said that we read from one side to the other of the screen, which means that implicitly our eyes are constantly seeking invisible “grids” to stick to.

That’s why indentation is important; it helps you to focus purely on the functional aspect of your code, without struggling to chase pieces around the screen.

Avoid deep nesting

This was a common pitfall for the early JavaScript developers (for reasons that are beyond the meaning of this article), but I’m sure that there is still someone around that is masochistic enough to continue this practice.

Generally speaking, avoiding deep nesting is simple, just delegate tasks to specific functions.
It’s all about defying the laziness and thinking modularily :-)

Return as soon as possible

This is more a performance tip than an aesthetic one; even if returning as soon as possible might save you extra conditions, leading to a leaner code.

What does it mean to “return as soon as possible”?
If your function receives an error or an empty argument that is instead mandatory or you reach a point where the output is ready, just exit from it.

There is no meaning to continue the computation if the mandatory criteria are not met or if we are fine with the result.

Divide et impera (Separate concerns)

For those who studied from books, this should sound familiar.

To separate concerns means that the “let-me-do-everything” function should be avoided (the same applies to classes and more complex structures).

It’s important also because it pushes the developer to take an initial mental effort to truly understand the functionality so that he/she can break it up into small pieces; so small that, in certain cases, they might be considered agnostic to the domain of the initial functionality (code reusability anyone?).

Make it as parametric as possible

Parametric means configurable and configurable means customizable which, in most cases means also reusable.

So bear in mind that hard-coded values should always be avoided at any cost.

Many arguments = use an object

My golden rule is that when I reach the point where I’m with more than 3 arguments for a function I consider doing two things:

1) simplify the function furthermore (if possible)
2) use a single “options” object as an argument (that would wrap all of them)

Having a function with many arguments might be a pain in case you’ll need to make just some of them optional, or to add/remove others and who knows what else.

Be consistent

Now grab all the suggestions above and (if you agree) apply them, always.

Inconsistent code is acceptable only for a short period of time (waiting for a big refactoring for example), with the time passing by it will become just a badge that will demonstrate how lazy the maintainers have been.

If you work in a team it’s also good to agree on common principles and rules to follow. Linting software is a helpful gear in the development mechanism.

At the end, we play with words, instructions and numbers and we arrange them in beautiful compositions; so let’s be digital poets, then developers.

If you reached this point and enjoyed the thing, remember to like it and, why not, to share it.

In any case, I wish you a lot of blingy-blingy lines of wonderful code.

One last thing: feel free to bug me in the comments if you want to discuss some point or if you have suggestions; you’ll be more than welcome.