To wrap, or not to wrap?

Both ways work.

covers.forEach(cover => {

covers.forEach((cover) => {

jslint is saying this way.

Hi,

It totally depends on the ide or compiler you are using.
for example in your case jslint/eslint both have documented this that in arrow parens you have to wrap your variable/function in parens to avoid ambiguity.


09%20AM

Parenthesis around function parameters means that you are less likely to make silly mistakes when you are working with the code.

Always use parenthesis around function parameters.

1 Like

The code that’s under question is:

    covers.forEach((cover) => {
        cover.addEventListener("click", coverClickHandler);
    });

It can easily be argued that this is not a suitable use for arrow notation as it doesn’t save any space, and it doesn’t make sense to refactor the arrow notation to a separate variable name.

If it was going to be arrow notation, it might be extracted out to a separate variable like this:

    const addCoverListener = (cover) => cover.addEventListener("click", coverClickHandler);
    covers.forEach(addCoverListener);

But it can be easily seen here that there’s no real benefit gained, and the addCoverListener arrow-notation function isn’t going to see any beneficial reuse either.

Instead of that, it is much more appropriate to use a function expression there instead.

    covers.forEach(function addCoverListener(cover) {
        cover.addEventListener("click", coverClickHandler);
    });

It is a matter of taste. It is just another meaningless debate that adds to the other matter of taste questions:

  • semicolon or not
  • tabs or spaces
  • double or tripple equals

My personal rule is: use as less syntax as possible. Where there are less characters, less lines involved, there can be less problems.

So use no semicolons, no tripple equals, no spaces (1 tab is only 1 character) and no parentheses when they are not needed. But that is just my opinion :man_shrugging:

https://drewdevault.com/2018/07/09/Simple-correct-fast.html

1 Like

He’s using a linter as a style guide, in which case it tends to be better to remain with the linter recommendations.

1 Like

I strongly suggest using ESLint with the AirBnB rules or extending Prettier. I’d say AirBnB’s rules are by a wide margin the most used default ruleset out there.

1 Like

Then I don’t understand the question… If the linter says no, why go and ask online whether they should do it otherwise? Clearly, they are asking for more opinions than their linter can give them.
But yes: if you already have a linter in place, especially in an established project, keep up with the rules, unless you have good reasons to change them. And from what I see, the original poster wanted to know community feedback whether to wrap or not to.

1 Like

Though it’s worth pointing out that this isn’t actually a matter-of-taste in quite a few circumstances/languages…it’s actually a different functionality. (string index 0 is NOT the same as getting false…)

It’s also worth pointing out that if you have more than one parameter in a fat arrow function, you have to wrap them. Personally, I do wrap single parameters, just for consistency if I have to later use multiple.

1 Like

+1 @m_hutley

Always use strict equality otherwise you’re going to look at a serious bug infestation if you’re writing anything remotely complicated. There are only a few very rare cases where you’ll need to use double.

@mawburn @m_hutley oh boy what did I start again :smiley:

I wouldn’t say double equals is less secure by nature of the double equals, but by nature of insecurity around our variable values.

Read more: https://www.reaktor.com/blog/fear-trust-and-javascript/

I firmly believe that we should trust our state by using e.g. immutable state. Not necessarily achieved by libraries like immutable.js but with contracts built up around functions.

Function Contracts

This is easily achieved doing functional programming. Then you don’t validate a random variable that can be changed all the time, but a functions outcome.

There are some very obvious cases where you can always trust a specific source to be always the same type. If you know the contract built around a specific function, then you can always count on retrieving the right type. And if a function fails, you can still count on a falsy value (null, false, 0, NaN) or an error thrown.

The Built-ins

When I call .toLowerCase on a string, I don’t get an unexpected type out of the blue. It always will return a string, (so as long as I operate on a string). It won’t be all of a sudden null or undefined or false. I ALWAYS can count on that I will receive a string back.
No need for triple equals.

Same for some keywords. instanceof will not all of a sudden be a String or a Number. I can always count on the interface of that keyword to give me true or false.
Same with typeofwhich always gives me a String.

The only good reason I see to use triple equals is if you are uncertain. But this will not save you from the problems caused by not knowing what a function does.
Should we build our software for developers that do not even try to understand the nature of a function and/or not read the documentation?

More to read: https://frontendmasters.com/courses/javascript-foundations/implicit-coercion-loose-equals/

I err on the side of caution. Using triple equals means that you don’t need to rely on people having a perfect knowledge of how double equals works.

2 Likes

I’m sorry, but none of what you talked about here supports your point. These things are completely unrelated. Strict equality and lose equality are very different things. It’s not about insecurities, it’s about building code that works reliably. Using loose will lead to bugs and those bugs will be extremely hard to trace down, that’s just a fact that I have learned from experience and is supported by every respectable expert I’ve come across.

If you’re the only developer on the planet in the history of software development who builds completely bug free code and you work in a complete vacuum, then I’m sure this isn’t a problem for you. But for the rest of us plebs it is. It’s not about when it works, it’s about when it doesn’t.

2 Likes

This topic feels to be meandering a bit. My take is the question boils down to
“should I tighten a loose typed / syntax language when possible?”

Personally, “looseness” increases the chances of me introducing a bug so I tend to avoid it as much as possible. I prefer to write code that is easy to read. True, there are some that can write “elegant” code that does what my multiple lines can do in a single line, but that’s not me. I’ve never experienced increased readability bytes causing a noticeable problem. I use braces, parens, semi-colons etc. even when I don’t “need to”.

I imagine there may be times when code can be written to take advantage of “looseness” (eg. type coercion?) but I have never needed to use looseness as the only way it could be done.

tl;dr wrap?
I feel consistency is usually a good thing, find your preference and stick to it as much as possible. Adopting the conventions of a linter isn’t a bad idea, if you like them.

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.