DEV Community

8 techniques to write cleaner JavaScript code

Muhammad Ahsan Ayaz on January 03, 2022

I believe being a Software Engineer is just like being a Super Hero! And with great power, comes great responsibility. While writing code is an int...

Read full post

Roman K • Jan 9 '22

The article was about general advises, and you are suggesting a functional programming approach which is worth a separate article :)

The approach is tricky, leads to unclean code (what createElement does? creates a function!) so I wouldn't recommend it as a general advise

Raghavendra Samant • Jan 3 '22

Great writeup Muhammud .

Q: const DAY_IN_MILLISECONDS = 3600 * 24 * 1000; // 86400000
isnt it better to put the breakup in comments to avoid the calculations being done every time ? Performance over ease of understanding

Muhammad Ahsan Ayaz • Jan 4 '22

Thanks Raghav,
I didn't understand the question. With const DAY_IN_MILLISECONDS = 3600 * 24 * 1000; we're performing the calculations one time and that constant can be used multiple times now. And we can definitely have a better comment around it.

Luis Rodrigues • Jan 5 '22

I believe that what Raghav meant was, if you put this variable in an kind of component that calculation will be done every time that i use the component.

use this:

const DAY_IN_MILLISECONDS = 86400000 // 3600 * 24 * 1000

Muhammad Ahsan Ayaz • Jan 8 '22

Oh. Yeah, definitely. This should most likely be in a constants file or something. You're right.

Andre Greeff • Jan 18 '22

I'm normally somewhat sceptical of posts in this category, simply because so many of these points end up being very closely tied to the wonderful concept of "personal preference".. that said, this has some real gems, with some good clear examples. nicely done!

with regards to the idea of avoiding short-hand variable names, I agree wholeheartedly with what you're saying, but (..and there it is) I have one small exception to this "rule": and that is dinky, tiny, one-liner helper functions..

using your first splitName function as an example, simply because of how small it actually is, instead of writing it like this:

const splitName = (nameString) => {
  return nameString.split(' ');
}

I personally would have written is like this:

const splitName = (n) => n.split(' ');

with that said, as soon as the function arguments start growing, or the function body requires more than a single line, then both the implicit return and short-hand variable names go straight out the window.. tied to a rock.. shot by a cannon.. sometimes without even opening the window first.. (:

Roman K • Jan 9 '22 • Edited

Agree, makes sense now, I get used to rely on naming and I'm not hovering things at all, while in this practice programmer has to rely on hovering hint. I've tested and it works nicely, even in plain JS I got hint

log = (prepend: any) => (log: any) => void

Libraries is a different thing and only way is it read docs and memoize frequently used stuff.

$.get - jQuery was intended to do what document.querySelector does before it appeared, so I expect it to get element by selector. I honestly didn't check docs. But if it was ramda I would expect: get(key, object) and get(key)(object), but wrong, it's a 'prop' in ramda.

1 nowadays we have inline docs and typing systems.

So in general thanks for response, in editors it's not hard to get hints.

But not everywhere, while reviewing code in github it can give you hints as well, but far less intelligent and it won't work so nicely.

2 and 3 isAnObjectWhichContainsARankQAndASuitOfSpades

I would have a type Card = { rank: string, suite: string }

And a function getIsCardAQueenOfSpaces.

And now I can assign it to local variable isQueenOfSpaces and use it in imperative way

4 Makes sense, but it means whole project need to follow FP and currying to stay predictable, everyone in team must be good with FP and be on same page

Do you use libraries without knowing what the utils they provide will return, and relying only on the name?

Yes, sure, other teammates may introduce libs which I never used and I'm reviewing the code, and usually it's understandable just by looking on name and usage

Robert-Rynard • Jan 11 '22

For default object values is there a reason you are spreading out the two objects. Is there an advantage over doing

const createButton = (config) => {
    return {
      color: "#dcdcdc",
      disabled: false,
      title: "",
      padding: 0,
      ...config
    };
}

or using the default values in the arguments?

const createButton = ({ title = "", color = "#333", disabled = false, padding = 0 }) => {
  return {
      title,
      color,
      disabled,
      padding
  };
};

Roman K • Jan 9 '22 • Edited

Guess what isQueenOfSpades contains in ramda docs? Guessing not works in here, in such way need to read source to know. While in normal JS where naming matters it is a boolean.

Is it clean? In common programming sense, name is given to describe what function or variable does, so in this way no, it's not clean. Functional programming has roots in math where naming doesn't matter, they are cool with formulas like this one, but it's not right to expect your teammates will be happy of guessing how your log works.

Muhammad Ahsan Ayaz • Jan 4 '22

@lukeshiru You're right. Thanks for the tips. I tried to keep things in this article (and the video). But yeah, once we get the pipe operator, things are going to be much more fun.