DEV Community

Clean Code in JavaScript: A Comprehensive Guide 🚀

Alaa Samy on February 22, 2025

Writing clean code is an essential skill for any developer. Clean code isn't just about making your code work—it's about making it work elegantly, ...

Read full post

Alex Lohr • Feb 23

About #2 using classes to organize data: it is always a bad idea to conflate data with functionality - and wrapping everything in getters and setters will just inflate your code. Unless you need to take action on getting and setting, those are pure overhead - and otherwise, use actual getters and setters so the users of your objects don't need to inflate their code, too:

// Don't! 
class User {
  #name; 
  constructor(name) {
    this.#name = name; 
  }
  getName() {
    return this.#name; 
  }
  setName(name) {
    this.#name = name; 
  }
}
const user = new User(name);

// Just do
const user = { name };

See how much complexity vanishes just because you handle data as data and not as class?

Massimo Artizzu • Feb 23

💯

Also, if you really need to set a getter and a setter, you could also use the newer and leaner syntax get name() and set name(name).

Unless you need to pass arguments too (which is generally bad IMO, as long as the method name suggests a simple data read).

Peter Vivo • Feb 23 • Edited

You are right: Function is the heart of Clean Code.
But let's realize a main difference between the arrow function and the classic function.
The classic function have hoisting and can be used as class.
Arrow function is much modern, don't use inner this and for a good reason have a return value.

because in your example:

// Good
function processUserData(user) {
  if (validateUser(user)) {
    saveUserData(user);
  }
}

function saveUserData(user) {
  updateUserInDatabase(user)
    .then(sendWelcomeEmail)
    .then(updateUIWithUserData);
}

All of these functions are inpure because use some outer dependency like saveUserData(user)

My advice is we need to make distinct ( at least in mind level ) between the pure and in pure function.

If we would like to make our function with outer dependency are testable then better to use dependency injection:

/** 
 * @type {( 
 *    updateUserInDatabase: (u:User) => void,
 *    sendWelcomeEmail:  (u:User) => void,
 *    updateUIWithUserData:  (u:User) => void,
 * ) => ( u:User ) => Promise<void> }
 */
const saveUserDataFactory = (
  updateUserInDatabase,
  sendWelcomeEmail,
  updateUIWithUserData,
) => async (user) => 
  updateUserInDatabase(user)
    .then(sendWelcomeEmail)
    .then(updateUIWithUserData)
  ;

Alaa Samy • Feb 23

It's a really good approach! Thank you for sharing this 😊

Yangren • Feb 23

Good article, thank you :) I didn't quite understand your example on naming conventions though. Can you explain why getUserInfo, getClientData and getCustomerRecord have inconsistent naming and are bad?

Alaa Samy • Feb 23

I am glad you find this article useful 😊.

Let me explain the inconsistency in the naming functions (getUserInfo, getClientData, getCustomerRecord )
These functions use different terms (Info, Data, Record) and refer to essentially similar concepts (User, Client, Customer), and this might be confusing to someone who reads the code and might not recognize what these functions are related to.
Also, these naming variations make it hard for developers to remember and search in the code, and figure out which function to call.

I hope this clarifies things for you, Feel free to ask any further questions

Massimo Artizzu • Feb 23

That's good, but don't explain in the comments: explain in the article.

Gabriel Almeida • Feb 23

I think is because all of them have different names for the same functionality, get the user data (sorry for any mistakes, English isn't my native language)

Ilya Belous • Feb 23

Wow, what an awesome deep dive into clean JavaScript code! 🚀 This guide is a goldmine for anyone looking to level up their coding game—whether you're a newbie or a seasoned dev. I love how you broke it down into actionable tips like meaningful variable names (goodbye, cryptic d and arr!) and keeping functions small and focused. That “do one thing” rule is a game-changer—I’m guilty of writing those monster functions that try to do everything at once. 😅

The modern JS features section is 🔥—optional chaining and destructuring are my go-tos for making code cleaner AND more readable. And that tip about writing comments for “why” instead of “what”? Spot on. It’s so tempting to over-comment the obvious stuff instead of explaining the real intent.

Quick question for the community: How do you all handle naming conventions in big projects? I’ve been leaning toward camelCase for consistency, but I’d love to hear your strategies! Also, any favorite tools or linters you swear by to enforce clean code? (ESLint fans, where you at?)

Thanks for dropping this knowledge—definitely bookmarking it for my next refactoring session.

Alaa Samy • Feb 23

I'm thrilled to hear that you found the guide helpful 🌟,

When it comes to naming conventions in big projects, consistency is key.
Personally, I stick to camelCase for folder names, hooks, and utility files, and for components I use PascalCase, It helps keep everything organized and makes the codebase easier to navigate.

Thanks again for your kind words and for joining the discussion! 🚀

JakeHadley • Feb 23

I really love the ai generated circle of interactions y'all got going on. It's almost like it's real life. Great ai article as well. Maybe I should do one on Rust clean code when I know nothing about Rust.

Alaa Samy • Feb 23

Thanks for your comment!

Actually, I wrote this article based on my experience working with JavaScript and studying clean code principles, even though I did use AI tools to help organize and format some content (as many writers do with tools like Grammarly or spell checkers).

Contributing to the developer community is valuable, and the focus should be on the content quality and usefulness rather than how it was created.

I'd genuinely encourage you to write and share your knowledge! and I'd be happy to discuss any specific points about clean code practices in JavaScript if you have questions or insights to share.

Riccardo • Feb 23

Nice to see Clean code in the Javascript world. It would be good to acknowledge the masters of the past.

Massimo Artizzu • Feb 23

Author, answer honestly: did you make use of AI to write this article?

Many points are fine (some are quite naive), but they're all under-explained, and the examples often do no justice to the principles. Hand-crafted examples don't usually suffer from this problem; AI generated ones usually do. Also, AI often uses older JS syntax (e.g. getName() instead of get name(), || instead of ?? - which is a little ironic because it's in the section "Modern JavaScript Features") (also those greet functions are not equivalent: try passing an empty string, and see how the "bad" one probably does what you actually want, while the "good" one fails).

And you didn't mention that if you want to write unit tests like those, you need a library like Mocha/Jest/Vitest/etc. And the fact that those are unit tests, while you probably also need integration, end-to-end, performance and accessibility tests too. And more.

If you want to make clear why a principle produce clean code, take inspiration from ESLint's rule explanations (e.g. how they explain destructuring). They show a lot of general use cases, options and nuances for every rule.

Alaa Samy • Feb 23 • Edited

Thank you for your feedback!

You're right about the depth of explanation, but this post was intended as a high-level overview to introduce these concepts, particularly for developers newer to clean code practices, and each point of these principles need a follow-up article to cover it in more detail.

And I want to clarify that the principles shared come from my practical work with JavaScript and studying clean code principles, I did use AI tools to help in organizing the content (not writing the code), similar to how writers might use tools like Grammarly or editors to improve clarity.

Regarding the greet function examples, you're right that the 'bad' example do better that the 'good' one, but these examples were intentionally simplified to demonstrate the concept of using default parameters over logical OR for defaults. In a real-world application we would need more validation for each function.

learndepth 2024 • Feb 23

alert("Hi")