10 Tips to Write Clean Code

"It's all about writing a code" No Please!

It's about writing a good & readable code, refactoring a lot for better results, optimizing, structuring, organizing, analyzing user requirements, designing, building, testing, etc... believe me, this won't end

In this article I'll be sharing my experience how to write a clean code, anyone can learn new technology & implement it, but we must always follow best practices, & pay attention to minor details 😊

---

I'll divide the process into 10 steps (will try to make each point short as possible & hope it will clarify or help you to become better in your coding journey)

1- Simple & Readable

• My code should a junior & senior understand it, naming, structuring your code in a simple & readable way will make your life easier before others
• By simple I mean it direct, easy and it covers the purpose, where's at the same time will be readable

2- Having your own standard

• Find your own style & standard this will boost your productivity especially when you're dealing with multiple projects
• It will make you become quicker with changing stuff or updating a major portion of code

3- SRP (Single Responsibility Principle)

• A function that performs everything, this is literally a headache
• Let's make our functions responsible for a single task, this will make your function clean and easy to understand, scalable & much more flexible. And try to keep the arguments as few as possible inside the function

4- Avoid comments

• Avoid commenting old features or old code (to tackle this master git 😉)
• Avoid commenting to specify the purpose of a line or "what it does"
• Your code must not need any comments to be understandable
• Only write a comment iff you have something related to a third party, and make it short as possible (the aim of this is to clarify things for another developer) but again even if you are using some third party API's your code must be easy & direct, the new developer can access the documentation & figure out everything so there's no need to comment here too

5- Your code should be easy with others

• Let's make the code as simple as possible & while making your code simpler, is actually the process of optimizing it
• Be direct and always think of others (is this readable? will they understand it? will I after 2 weeks?)

6- Whitespaces & Indentation

• Many people think using extra of these will make it harder to read or even it will affect the compiler 😄
• I recommend using as much as possible, just check the examples below and you will know what I mean

const fetchUsers=()=>{
let response=['some data'];
return response;
}

const fetchUsers = () => {
    let response = ['some data'];
    return response;
}

7- Organize your project

• A good folder structuring, & easy file access are just perfect meaning for a happy life 🌴
• Structure your code so that others can search for folders & files easily, make it ready to scale and organized as much as possible

8- Meaningful & Direct names

• While coding you will be writing a lot of names for variables, functions, classes, arguments, modules, packages, directories, etc...
• It will be a good practice to write a code that is clean, easy to understand & just meaningful, check the examples below

let cars: array = [];
let myCars: array = [];

both of them are easy & readable I know but which one is direct & easy for the developer to know its purpose?

• Another example:

const searchUser = () => {}
const searchUserByName = () => {}

Here if the first one is generic go with it, but if the function does a search by the only name then use that one, the idea is to name your function what it does only

9- Avoid repetition

• Always make sure your code is reusable & scalable
• Break down a task into smaller chunks, and make sure at least 90% of it is reusable

10- Refactor

• Read other codes, optimize them & make them cleaner. I like using the term "compress", which means making it simpler & smaller
• Refactoring a code is a really good skill, it will make you aware of what's going on, & while you're refactoring, it will become better, it's always good practice to return to your code after a while & enhance it

---

These are some main points that I wanted to mention, still, there are many details that you need to take care of like unit testing, performance optimization, etc...

It's not just about the tech or the skills, it's about being organized too, hope this was clear & simple as how the code should be 😊 & I'm always looking forward to dealing with this kind of codes 😁
Thank you, and wish you all a great programming experience

Comments

[Andy Edmonds]

Solid post. I would extend the comments section to include two types of comments. First is a hack comments for when you have to put a working, but bad code block in to meet a deadline. I try to isolate this code it it's own function or class so the comment doesn't interrupt the flow. Second is answering why the code has business logic that is abnormal or a deviation from the rules the rest of the code follows. There is always a stakeholder who requests weird things at the last minute.

I completely agree about the comments telling me what the code does. I always delete those when I see them. Too much effort to maintain code and a comment in that situation.

[awedis]

Yepp 100%, if a code has been written in a really good way, I believe the comments will be just a distraction

[O ji nwayo e je]

We need a downvote button urgently

[Siddharth]

Sorry about that. It's just the way I am and I am trying to change. Can you please tell me the first time?

This is my first interactions at a community and I want to get better at communication — The one thing I am bad at

[simonki73]

could have directly returned, but not should. Depending on your IDE, separating the statement over 2 lines can help you set a breakpoint and step into it. So I'm standing behind the OP on this one.

[Siddharth]

Good point.

[Siddharth]

number 6 is actually bad code, but it's a demo so okay...

[awedis]

yep, the idea is to see the difference, which one is cleaner and easy to read it :)

[Siddharth]

I mean that you should have directly returned.

[awedis]

yes that can be done, I wanted to showcase more indentation

[Giancarlo Corzo]

Comments are important specially in large and legacy codes. I would suggest to add comments every time you are doing something that is not obvious from the code.

[awedis]

Comments can be used true, but what you mean by "something that is not obvious from the code" (if it's doing something extra not related)? what I meant here is that a code shouldn't need comments from the start if it's written in a good way

[Giancarlo Corzo]

For example, some time ago I was working on a legacy code that get information for a list of credit cards and for some reason in this code was removing a especific information for some type of cards. It was obvious from the code that he was removing this information, but it wasn't obvious why he did this. The coder was long gone and I had to spend ours trying to figure it out why he remove this type of cards.

Finally I much testing I understood that was becuase the info providers was sending the wrong information for this cards and the coder had to improvise (hack it). A comment would've save me time because you are documenting a decision that is not obvious from the code.

[Shubhendra Singh Chauhan]

Good read 👏