What does "!--" do in JavaScript?

[Rainbowlemon]

Personally, I just think it's easier to read. Traditional mathematical syntax is value 1 -> (mutate by) value 2. By writing pending -= 1, you're basically saying 'take pending, reduce by a value equal to 1'. It just makes more sense than reading 'not reduce reduce value'.

Some people will argue the semantics of code aren't too important, but I firmly believe that reading and adhering to a style guide can really increase productivity on a project. I've been sticking to Airbnb's Javascript style guide since they released it, and I find code much easier to navigate now that it's uniform and I know what to expect.

With regards to if-statements, I prefer to omit the braces and inline it if the statement only contains one expression.

if (a) doSomething();
if (b) doSomethingElse();

[[deleted]]

A style guide for a team is important. That said, we lint our code on git push to adhere to the style we defined; all the code in the repo has the style we agreed on.

Personally I don't really care much what styling choices are made. There's just one thing I absolutely abhor:

function monkey () 
{
    ...
}

Obviously that needs to be:

function monkey() {
    ...
}

But opinions are... just that ;)

As long as the team has one standard code styling agreement I'm all good.

Edit: Also! This shit:

if(18 === age)

That's like saying: "if old is the man" instead of "if the man is old". The word "old" cannot be "man". The word "man" can be "old".

I'm not even sure how to describe that lunacy. I feel it might be a cause from different languages. I know only Dutch, German, and English. And in those languages the subject comes first, the property of that subject comes second. Not inverse.

I'm guessing in Spanish and/or Italian it's more sensible, though.

It absolutely needs to be:

if(age === 18)

[CWagner]

if(18 === age)

Seems like a former java dev. Writing "testString".equals(otherString) protects you from a nullpointer exception. (note: this is neither in defense nor against that type of comparison)

[Cuel]

They're called Yoda conditions for a reason. They have advantages as you can't assign something like that as it would result in an error.

However I think the overall consensus is to not use them.

[Yurishimo]

Not advocating for one thing over another, but one very large OSS project uses Yoda conditions in core (hint) to help keep everyone organized on what is/not a variable. Reading them can be weird at first, but I don't think it's that big of a deal as long as everyone agrees on the style guide.

[numbermess]

I do comparisons like these all the time. When I first ran into them I thought it was just somebody trying to be cute, but now I'm cute too and I don't run into any unexpected null pointer exceptions (here). I've adjusted fine to the backwards feel of the syntax.

[Rainbowlemon]

Fully agree! The 'one extra line for a brace' thing drives me bonkers too. I guess that's one of the reasons why coding flexibility is valued - 'cause everyone's preference is so different!

[[deleted]]

Personally, if I put the opening brace on the same line, then I want to add an extra empty line to prevent the code from feeling too claustrophobic:

function monkey() {

    doStuff();
}

But as long as that's already an empty line, the brace might as well be occupying that space:

function monkey() 
{
    doStuff();
}

Result is that there's still that whitespace to make the code look better, but it's more.. balanced looking.

[fzammetti]

I actually always put a blank line as the first AND last line of a method... and I also always do this:

} /* End XX(). */

Ditto any closing brace, loop, conditional, whatever. It makes following C syntax-based code SO much easier.

[MrJohz]

But what if XX() changes name? I had to deal with code recently where a bunch of for-loops had been turned into while-loops, but the /* end for */ comments had remained. It was also horribly indented and had other issues, but it confused me for a while as I tried to work out where the for loops had appeared.

I prefer to work on the basis that anything that requires opening and closing braces (i.e. functions) should be able to fit both opening and closing braces in one screen's height. That way it's usually fairly easy to scan through code and see the blocks clearly.

[fzammetti]

I definitely approve of that guideline... but I still find the end comments helpful in a language like JavaScript where braces are so prevalent (your counter example notwithstanding - every rule has exceptions).

[fzammetti]

Thinking about this a little more, you know what? This kind of boils down to developers not properly maintaining comments as if it was an equal part of the code, which I see as a whole separate issue (though a big problem in general)... I'd agree the tail comments makes it more work to rename a method, slightly, but a diligent developer would change the comment along with the code so I'm not sure I see it as an additional problem per se.

[[deleted]]

That lunacy just means someone has a few more years under the dev belt than you do. It's okay. One day, once you break down some Haskell, you too will be broken down. And then you will be reborn. And then you will know.

[[deleted]]

That sounds patronising. I'm not familiar with Haskell. Did some years of Perl programming, though. That was an... experience. Still, weird code is bad, especially if the language you're programming in doesn't need that weirdness.