DEV Community

loading...
Cover image for 10 Tips to Write Clean Code

10 Tips to Write Clean Code

awedis profile image awedis ・3 min read

"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;
}
Enter fullscreen mode Exit fullscreen mode
const fetchUsers = () => {
    let response = ['some data'];
    return response;
}
Enter fullscreen mode Exit fullscreen mode
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 = [];
Enter fullscreen mode Exit fullscreen mode

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 = () => {}
Enter fullscreen mode Exit fullscreen mode

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

Discussion (16)

Collapse
socratezz profile image
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.

Collapse
awedis profile image
awedis Author

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

Collapse
mmayboy_ profile image
O ji nwayo e je

We need a downvote button urgently

Collapse
siddharthshyniben profile image
Siddharth

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

Collapse
lifelongthinker profile image
Sebastian

This is the second time that I see you criticize someone's article in a somewhat destructive way.

It's okay to criticize, but can you please do it in a way that is (a) respectful towards the author, (b) constructive towards the discussion.

Your comment here is neither.

This is a great community with really awesome people. Please let us all try to keep it that way. Thank you!

Collapse
siddharthshyniben profile image
Siddharth • Edited

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

Thread Thread
lifelongthinker profile image
Sebastian

Thanks for your understanding and consideration.

Collapse
awedis profile image
awedis Author

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

Collapse
siddharthshyniben profile image
Siddharth

I mean that you should have directly returned.

Thread Thread
awedis profile image
awedis Author

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

Collapse
simonki73 profile image
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.

Collapse
siddharthshyniben profile image
Siddharth

Good point.

Collapse
giancorzo profile image
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.

Collapse
awedis profile image
awedis Author

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

Collapse
giancorzo profile image
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.

Collapse
withshubh profile image
Shubhendra Singh Chauhan

Good read πŸ‘

Forem Open with the Forem app