JavaScript is one of the most flexible and lenient programming languages out there, compared to the likes of Java or C++ which have much stricter r...
For further actions, you may consider blocking this person and/or reporting abuse
I don't agree with point 5, omit semi colon but do ommit braces? That is the same issue. Do use braces, don't rely on whitespace. Or do the opposite, don't do both.
Using braces even for only one statement was in our guidelines on a previous project. A new guy "defied" it, saying it was nonsense. Then it bit him in the a** a couple of times. Now he uses them everywhere. Not just in JavaScript, but also C#.
If they're missing I'll add them. If someone removes them. Hmmm... OK let's stop here for alibi purposes. :D
Oh futher reply, Michael it's not about brace or not to brace that I respect about your comment, it's that you have a good strong opinion. That is the most important part. I always say, it can be consistently good or consistently bad but atleast it's consistently changeable.
Whatever we decide is punishable by death, stick to those guns and lint, lint, lint.
Ultimately it's 31+ years of experience (and I still have SO much to learn; things change so fast in this field - .NET Core 3.0 just landed and I'm all excited), and a lot of that experience was going through pains of even little things like that that often cost us hours or days and could have been avoided with better practices, etc.
Many of my coworkers have come to learn that if I'm really insisting on something and speaking strongly in favour or against something, there's a good reason (which they may or may not understand yet, depending on their level of experience). I'll sometimes fill them in on horror stories while having a cold beer at a nearby restaurant. :)
In our project we have a linter which won't let you commit unless you fix your code. It's a sure fire way of getting everyone to behave the same way, because that is all it's really about.
Can you tell me what tools you are using for linting? That would be useful to us since we have been bringing in new people on board (I've been on this project less than three months, some less and new one coming in soon), all with various levels of experience.
Sure, let's see, first sass-lint, that fails in CDCI, then we have es-lint with the Airbnb preset (it's a good one) we extended it and turned off a couple of js features that we don't transpile for per reasons. Lastly we have a strange stack with an equally odd templating language which is domain specific, so I adapted htmlhint with some custom rules to lint that (proud). Not all of the linting is switched on to fail CDCI yet and only JavaScript has a commit hook tool. The hook tool is quite new so I don't know the name but I will find out and get back to you.
Cool stuff, I'll look into that. Thanks! :)
I would be very interested in a link to whomever it is that doesn't recommend omitting semicolons. Is it ECMAScript? Is it a general consensus that I can find somewhere? Or is it a personal preference?
Can you provide some examples in which this is the case?
I'm not trying to challenge your point, I am honestly interested in the semicolon debate. It's just that I've never seen any compelling reason to use them.
The point is to understand where automatic semicolon insertion is going to cause bugs and avoid code that will allow it (preferably with lint rules) and then be consistent. The classic example is to avoid a
returnstatement that splits the returned value to a new line.Anyway I'll add a sixth best practice you should always follow:
Never follow advice that says you should always follow it. There are always exceptions :)
To the first part, this is the official styling guide by google
here
Note that ECMA Script does not force you to explicitly type semicolons. It does not recommend relying on ASI either.
To the second part, I might have to dig up some examples, but in general writing codes passing function expressions as parameters, object literals as parameters, and nested function calls can get pretty messy and even if pretified, without semicolons denoting end of statements, it is hard to follow code.
Google is Google it is not the overarching authority on JavaScript style. You are better placed following the lint rules of your project. ASI works but knowing where to put semi's is the problem for some people. I use semi because I follow my project nfr's, I used to omit them, now I don't care and I recommend both ways. They both work fine.
But that's just a style guide to ensure that Google code follows the same conventions all throughout. It seems to me far from any sort of official/widely agreed on recommendation. In fact, if we were to take the document's guidelines as best practices, it clearly contradicts your last point.
Maybe if the code is very messy. Personally I've never had trouble with those. Well, at least not any trouble that I thought would be solved or improved by adding semicolons.
For some additional information on whether you should / shouldn't rely on ASI, check out this post!
This is a great post, Umer, both for beginners & experienced devs.
As someone who comes from a c++/c# background, I find myself creating a few globals e.g “Site title”, “Author” and other meta-tags. Will be trying out your suggestions now 😊
This is a neat post. Here are some of my initial takeaways:
While I agree with you that you should not rely on ASI, it's really all up to whomever is writing the code. A lot of other people have pointed out that just because Google's style guide dictates that you should not rely on ASI doesn't mean that it is now written in stone. For some more information on why you should / shouldn't use ASI, check out this read for more information. It has a lot of good points, and only helped to reinforce the reasoning behind why I do not use ASI.
Any piece of code? You mentioned that even if you only use a snippet twice, you should function-ify it. While I'm all for cutting down on code re-use, if we were to abstract every segment of code away into functions... Well, now, what would that do for your program's readability? 🤔
I tend to agree with this one as well, but with a huuuuuuuuge caveat: keeping your code consistent is as important, if not more, than keeping your code concise. You mention removal of the brackets as one way to help improve readability and limit redundancy.
Humans, however, have a much easier time reading when there are detectable patterns (consistent use of brackets is a good example of this). When you do not follow a pattern, reasoning about the code becomes decidedly more difficult. While I have other opinions about keeping
ifstatements on one line, I almost always use the optional curly brackets. I would argue that omitting the curly brackets does little to improve readability. Often times, I would argue the inverse 😅On the whole, while I certainly agree that a lot of these concepts are important to learn, only some of them pertain directly to Javascript. Things like abstracting reused code into functions and keeping things concise and consistent are just best practices when it comes to programming at large.
Strong disagree with 2, 3, and 5.
Code is for humans. Readability is above all.
Concise code != Readable code
There will be times when a for loop is easier to read than a higher order array method.
For instance, handling async code within a map or reduce is far more difficult to read than a loop.
Very rarely will the lack of semicolons cause bugs or unwanted side-effects. Several linters and code editors can be configured to highlight exceptions.