Clean code is important, clean code helps others understand your code, but clean code is also pretty subjective!

I want to give you my perspective on it, drawing from years of experience leading teams of developers as a tech lead and working in teams.

Clean code is important

Clean code helps people understand code.

The more your code is structured according to the opinion of the majority of developers, the more likely it is that other developers will understand your code!

A few principles of clean code are:

- Use meaningful and understandable identifiers
- Use functions and keep them as short as possible
- You don’t need comments most of the time when your code is human readable
- Don’t repeat yourself (DRY)
- Keep it Simple, Stupid! (KISS)

- Premature optimization is the root of all evil
- Tell, dont ask (TDA)
- Law of Demeter
- Separation of concerns
- Single responsibility Principle (SRP)
- Open Closed Principle (OCP)
- Liskov Substitution Principle (LSP)
- Interface Segregation Principle (ISP)

- Dependency Inversion Principle (DIP)

Clean code helps others understand your code

Each developer has their own style of coding.

There are things they like, and things they don’t.

They prefer doing things in a certain way, because it works best for them.

By leveraging well-known principles and integrating them into our own work, we open up the possibility to others, who are themselves aware of those principles, to find their way into our code base easier.

It’s like using standardized technology!

Take a Dockerfile for example. The syntax is mostly standardized nowadays. If you can write a Dockerfile to use with Docker, you could also create a container with podman because even most commands are standardized and the same!

Now transfer this over to how we write code.

You can surely imagine that understanding becomes easier when many developers leverage the same principles to write and structure their code!

Clean code is subjective

As you’ve seen above, clean code leverages a lot of principles. But principles are what their name states.

It’s almost impossible to give everyone a strict way to do things in certain situations.

This leads to a lot of interpretations of clean code.

Take a readable identifier for example.

function getDogs(ctx) {
[...]
}

vs.

function getDogs(context) {
[...]
}

Could you tell which one is more readable?

If you ask 5 developers you’d receive 10 different answers.

This is one example of the subjective part.

For some developers, the abbreviation ctx is well-known, for others it’s simply not, and they’d prefer the identifier context.

The same goes for the length of methods, or how much interface is too much, or not enough.

Dealing with it

Discuss clean code with your peers and translate every principle into a certain ruleset for your team.

Decide, together as a team, how you want your code to look.
Discuss again if someone changes their mind.

Build yourself a set of rules and best-practices which all team members can agree on.

This way acceptance rises significantly and people will be more willing to follow the given rules.

Whenever possible, leverage automation, like linters and such!

As long as tools are configured according to what your team decided upon, there is no need for manual work or lengthy discussions in reviews.

If the tool says you’re doing it wrong, you have to adjust.

If you think the rule sucks, discuss it as a team!

Clean code as a beginner

Many beginners and/or newbie programmers tend to get overwhelmed, which is pretty understandable.

Not only do they have to learn to write code, everyone also tells them to do so properly.

Want to read my opinion on this?

Concentrate on learning how to properly make software work first.

You can still learn how to properly structure your code when you’ve taken the most difficult obstacles.

Learning what variables are, how loops work, what the DOM is, how a network works, and what TCP does is...

...already a lot to grasp in the beginning.

If you also add cleans code principles on top of it, I could understand if many people would simply get overwhelmed.

Better concentrate on the basics first, then try to get into clean code when your foundation is solid.