![Cover image for 8 techniques to write cleaner JavaScript code](https://media.dev.to/cdn-cgi/image/width=1000,height=420,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F2cab86auqek9wqzpv79e.png)
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...
For further actions, you may consider blocking this person and/or reporting abuse
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
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
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.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:
Oh. Yeah, definitely. This should most likely be in a constants file or something. You're right.
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:I personally would have written is like this:
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.. (:
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
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 way4 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
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
For default object values is there a reason you are spreading out the two objects. Is there an advantage over doing
or using the default values in the arguments?
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.@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.
Awesome Article, Thanks for the great techniques, you provided in this great article
Anytime!! Thanks.
Hey.. Remember update your Twitter in your Dev Profile: dev.to/codewithahsan
I don't see the value to use piped functions (even with pipe operator) ? It's less readable and requires more code and characters.
I'm seeing a useful of pipe operator now. Thank Luke Shiru.
Great article! "Fewer or Named Parameters" and "Avoid Hard-coded values" are the ones that really stood out to me the most!