DEV Community

Cover image for What Are Your Best Clean Code Tips?

What Are Your Best Clean Code Tips?

dev.to staff on April 07, 2024

What are your favorite strategies for writing code that's easy to understand, maintain, and extend? Share your top tips and tricks for keeping your...
Collapse
 
sarahokolo profile image
sahra 💫 • Edited
  • Seperation of concerns: making sure one function does only one particular thing and is reusable if needed.

    • Accurate indentation and spacing.
  • Clear and concise comments

  • Self descriptive variable and function names

Collapse
 
sumanthlingappa profile image
Sumanth Lingappa

On a lighter note, the above bullet points are not indented correctly 😀
BTW, great share 👍

Collapse
 
sarahokolo profile image
sahra 💫 • Edited

Lol, in the markdown they were properly indented, but for some reason when I post the comment, it just did that. Tried editing it twice, eventually just left it like that😅

Collapse
 
gunabalans profile image
Gunabalan.S

Self descriptive variable and function names >> I use this, thus reducing the need for additional comments.

Collapse
 
keep_calm_and_code_on profile image
Alex Lau

My personal experience with the recommendation of low coupling is that it's helpful to write out a "plain English" version of requirements. For example, creating a report from data based on a 3rd party API may look something this:

  • User submits the filters for the report
  • Make a request to the 3rd party API
  • Parse response from the request
  • Write the report data to a file
  • Email the file to the user

After writing these out, it helps me think about how the code could be organized. For example, each of these steps should at the very least be in their own function and there's probably separate modules/classes that can be derived as well.

But I think the biggest advantage to operating this way is seeing when code may be mixing concerns. If I look at my code and it deviates from this list - eg the code for implementing the email logic is in the same function as the code that implements the API request logic - I've likely grouped things together that should be split out.

Collapse
 
marissab profile image
Marissa B

I use the same process. The act of jotting down that bulleted list might show that I'm missing a step or that some assumption won't work, which is best to catch before any code hits the screen.

Collapse
 
ben profile image
Ben Halpern

Think about the big picture. It's rarely about the code you're staring at, but how it fits into the system.

Collapse
 
canro91 profile image
Cesar Aguirre

This is my mantra. Knowing the big picture helps us to know when to stop making a piece of code cleaner and cleaner...

Collapse
 
kurealnum profile image
Oscar

This might be a strange strategy to some, but I try to avoid abstractions as much as possible. IMO, it's much easier to go back and abstract something for re-usability when you need to, instead of constantly trying to throw everything into a function or class.

Collapse
 
creotip profile image
Ruslan Elishaev

Actually, it’s well known software design principle known as YAGNI , which stands for “You Aren’t Gonna Need It.”

Collapse
 
algorodev profile image
Alex Gonzalez

I use SOLID principles as the base of clean code strategy. Trying to make your code reusable is a great column too. And the last one I use the most is TDD, to clarify in every moment what I want and how to do it the best I can.

Collapse
 
bellatrix profile image
Sakshi

descriptive names for variables and functions.
using functions to avoid writing same code again and again
importing functionalities from other files to separate like and unlike things
writing comments where ever required
keeping in mind, which is deprecated and using what's new and versatile

Collapse
 
jcfore21 profile image
jcfore21

I think there is a great reason WHY several people have already said well named functions and variable names is a common clean code practice. I can't stress the importance of that concept enough. The problem with most code is INTENT. If you are clear with the INTENT of your code then you will have created clean and easily maintainable code. Usually that means just break out some code into a WELL named function. If you start to write comments around functionality then that's usually a good indicator (code smell) that intent isn't clear and it needs to be separated out.

Other things of note:

  • SOLID Principles
  • Keep it Simple - don't write complex code no one can understand if the problem isn't complex. I like dumb boring code because it can be maintained and won't keep me up at 3am during an emergency deploy night.
  • Write tests - anything not under test is Legacy code. It can't be easily changed without possible wide spread effects on behavior. Well written tests can also help segregate your code dependencies and uphold SOLID principles
  • Write good comments about WHY you made a change IF and only when it's necessary. Never write WHAT you are doing..that's just repeated code
Collapse
 
imparable profile image
Joe

I agree. A lot of comments are usually a sign of code smell. Especially after the code has been modified several times, but the comments are never updated when someone is enhancing it or making a bug fix.

I have seen this way too many times in production. The CODE is ALWAYS the source of TRUTH, not the comments.

Function and variable names should be clear, succinct and avoid acronyms (that can lead to misinterpretation).

Also if you think there are not enough characters to give your function a meaningful name, your function is probably doing more than one thing, a sign that its time to refactor.

One last thing I would add is to also not waste time trying to optimise code before you are finished AND there is an actual need to make the program or process run faster. Otherwise you might waste a tonne of time on something that gets refactored anyway or thrown out all together in the end.

Collapse
 
heyeasley profile image
heyeasley 🍓🥭

Thanks.

Collapse
 
gunabalans profile image
Gunabalan.S
  1. When working on the front end, avoid using two full-fledged libraries simultaneously, such as Bootstrap and Ant Design (antd).

  2. Ensure that the same library is not included multiple times with different versions

  3. If parts of the code have been replaced with a new version, ensure that the old version is not left commented out, as this can be avoided.

Collapse
 
heyeasley profile image
heyeasley 🍓🥭

Cool.

Collapse
 
ccoveille profile image
Christophe Colombier

I starter writing something in a comment, and I talked about so many things that I ended up considering writing an article.

I hope you will find it interesting

Collapse
 
sapegin profile image
Artem Sapegin

I think the main ones I'm thinking about while writing code would be:

  • Avoid loops (and use array methods like map() instead).
  • Avoid or simplify conditions.
  • Avoid reassigning variables and mutation.

I'm writing a book on clean code, where I talk about each (and many more) in great detail with lots of examples, most chapters are available online.

Collapse
 
pavelee profile image
Paweł Ciosek

Keep clean design, code we clean-up later

Collapse
 
steves2001 profile image
Stephen Smith

A fundamental of this is whether the code is going to be under continual frequent redevelopment, if it is then my advice is where you may be looking at adding greater functionality over time e.g. file output format for example ensure you use dependency inversion and get your interface for the abstraction right prior to developing your different output classes and seriously think about your output formatting classes and their single responsibility. People that are talking about comments, probably need to review their code not their comments as it probably needs refactoring and proper variable/function names. For comments relating to writing down steps in plain English, look at UML there are techniques within it to do this.

Collapse
 
sapegin profile image
Artem Sapegin

I think the main ones I'm thinking about while writing code would be:

  • Avoid loops (and use array methods like map() instead).
  • Avoid or simplify conditions.
  • Avoid reassigning variables and mutation.

I'm writing a book on clean code, where I talk about each (and many more) in great detail with lots of examples, most chapters are available online.

Collapse
 
jaloplo profile image
Jaime López

Here is my quick tip, order alphabetically everything: params, methods, etc. The next person that comes to the code will have a quick way to find anything.

Collapse
 
thexdev profile image
M. Akbar Nugroho

Documenting your code like Java did. Even if we already followed any clean code rules, our code still difficult to read because someone else need to understand it line by line.

Collapse
 
priyaranjanjen profile image
PRIYARANJAN JENA

I mainly focus on variable and functions name and sometime i use comments to specify what that function does

Collapse
 
solankidixit profile image
solankidixit • Edited

i have always follow to create reusable clean code

Collapse
 
georgetaveras1231 profile image
George

Surprised I didnt see anyone mention mutability and side-effects. I usually think it is a code smell if mutability and side-effects are spread across a system. These should be generally as centralized as possible so that you can easily trace how your system interacts with the outside world.

Collapse
 
programordie profile image
programORdie

Ask chatGPT to write comments for my code

Collapse
 
iamspathan profile image
Sohail Pathan
  • Variable Name is Important/ I follow snakeCase.
  • Prefer Architecture MVC/MVVm/MVP
  • Write unit tests - VV IMPORTANT
Collapse
 
suhangly profile image
Johangly Sucre

make it easy to understand

Collapse
 
havespacesuit profile image
Eric Sundquist

Prevent file size bloat. Pull out functions/classes/hooks to their own appropriately named files (NOT utils!) to keep the file focused on one goal.

Collapse
 
baenencalin profile image
Calin Baenen

Using Spark instead ov writing the boilerplate CSS yourself.

Collapse
 
ezekiel_77 profile image
Ezekiel

clean and consistent naming convention