Semicolons cannot save you! - FunFunFunction #9
Вставка
- Опубліковано 20 сер 2024
- 💖 Support the show by becoming a Patreon
/ funfunfunction
By all means, use semicolons for consistency, or just because your team likes it that way because it’s more C-like, or frankly just because you like how it looks. But don’t buy into the religion that it absolves you from thinking about automatic semicolon insertion. The ASI is always there, and and you need to be always vigilant about it, no matter if you add semicolons or not.
Full script here: / bf991756174e
More reading: blog.izs.me/pos...
Whether you use semicolons or not, one easy way to protect yourself from ASI errors is to integrate ESLint into your editor.
- The `no-unreachable` rule will protect you from `return
4;` error (see 4:17, where it’d return `undefined` instead of 4).
- The `no-unexpected-multiline` rule will protect you from `a = b + c
(d + e).print()` error (see 5:57, where it became `a = b + c(d + e).print()` instead).
- The `semi` rule will help you enforce the same style across your codebase, by requiring or disallowing semicolons in your code.
I love this channel! If you're curious, I think I figured out what's happening at 5:35. The ['Hello', 'Goodbye'] looks like an array literal, but it's actually a property accessor for the object on the previous line. In that context, the comma is being interpreted as an operator (not a separator) so the contents of the brackets evaluate to the last expression, "Goodbye". The forEach method is therefore called on the array [1,2,3]. The variable "name" is undefined because it's assigned the return value of the forEach method, which is nada.
Well, you've convinced me. In truth I actually had no idea how the AIS worked, or necessarily even that it existed. It's one of those JavaScript things that I've just never questioned before. On the back of watching this video, I've removed every single semicolon for my current side-project, and it still works the same way it did before, but now isn't littered with semicolons. Thank you very much. :D
More comments of semicolons than actual bugs is a perfect example of the Duck falacy, ie, Bike shed problem.Excellent videos with clear logical thinking. Congrats!
I use semicolons to visually mark the end of the line / expression, in my opinion it's a good practice to use semicolons because like this the code is read easier, not because of ASI errors :)
+micnic90 I'm cool with that, but remember that because it's easier to read *for you* does not necessarily mean it's easier for others. I personally find that they make it harder for me. To my knowledge, readability is more or less a completely subjective term when it comes to programming - in typography and western languages, there is a lot of empirical research on large populations, but there is no research on programming to my knowledge.
+mpjme I myself find code without semicolons easier to read, although that is likely due in part to my programming origins in Lua.
5:34 This sort of issue can be easily resolved by putting a semicolon before the square bracket. It means you won't need to follow a rule of adding a semicolon at the end of each line, and you'll avoid a screw-up by the ASI.
Personally i still end each line of code with a semicolon (too many years of C/C++/PHP), but I've used this method while writing jQuery plugin code as a protection method in case it's being added into code that doesn't have semicolons.
+2thinkcritically Yeah, this is how I do it too.
I thought I was writing semicolons for uglifier. But just tried to uglify my semicolon-less code and it seems like the uglifier is smart enough to not break the ASI. How cool! Thank you!
What if I am emotionally connected to semicolons in my code? Shall I bulk erase them and risk trauma together with depression?
yeah thats what i am saying. emotionally connected - great
Step 1: grab a command line and navigate to your codebase
Step 2: npm install standard -g (optionally with sudo)
Step 3: standard --fix
Step 4: embrace the loss, try to get through depression quicker, and look for survivors in for loops
Ben Snow you forgot beer.. that's important. .
I just don't see what the big deal is regarding semicolons. Who cares! It's not like we are talking about something important like whether or not to use curly braces with single statement if/else conditionals :)
+Christopher Stephens Hahahaha, I love you! :)
+Moronicsmurf Not using braces has far bigger consequences. See Apple's gotofail bug for a practical example.
+crytocc oh I wouldn't take anything from Apple so serious. ffs they made iOS by stealing most anyway. But yeah braces is more important than most junior programmers seem to think. :)
@100407009902125951252 About the gotofail bug - it irks me a bit when I hear that as an argument for braces. I think there are good arguments for braces-always, but the gotofail bug is not a good example.
A single, very simple unit test would have saved that code. It's very obvious that the developer neglected to even attempt to write a test for the code. I also have a really, really hard time believing that this change would have been missed in a code review.
I think "use braces" is pretty long down the line of learnings that one can draw from that bug.
Well depends once again on your circumstances. Where i work we don't do test driven programming there is no time for it. So it's more a case of don't fuck it up from the getgo. But using braces is quite useful when doing code reviews. Coding in short hand is a abomination that shall be purged with fire. Because it's just lazy and sloppy and makes it hard to read when you'r jumping through a couple of thousand of lines of code in glance.
Don't think every code team work in the same way just because yours is doing it in a certain way or that you learned it school. =)
I think semicolon-less JS code looks prettier, just like I dig Stylus over SCSS or LESS. But in the end it doesn't pay off: you don't get paid with pretty code, you get paid with effective and maintainable code.
The example at 5:30 is brilliant and brings up a kind of veeery nasty bugs in the code. One might end up staring at those lines trying to understand what's wrong and lose dozens of minutes refactoring the lines until they find it was a semicolon away to be perfectly working code. Those are moments where the urge to kill rises.
(As a perfect April Fool's prank, google "greek question mark" and replace a semicolon with that in some code written by the responsible for the missing semicolon.)
Someone may say that's a pretty uncommon construct to begin with, but as codebase grows, the chance of having some weird constructs grows as well. Who knows what kind of mash-up code a developer may bring up when s/he's tired/distracted/annoyed/drunk/hurry/high on caffeine?
Perhaps omitting semicolons is mostly fine when you're the only one working on a project and have full control of what's the expected behaviour and so on, but in a team everyone should aim for code maintainability and readability, and that's also where style guides come from.
So, in the end, one should stick with semicolons? In my opninion yes, because they can actually save you from - maybe not for all, but for many - well avoidable bugs.
Should we completely forget about ASI and how it works? Absolutely not, because that's what prevents us from coding horrors like putting the return value in the next line.
Should we allowed to switch ASI off? No as well, since it deals pretty good results in minified code. (Or maybe a "use semicolon"; statement can do the trick? Meh.)
Also yes, other languages use semicolons at the end of their statements. C is just an example, but more strictly related to web development is PHP, where semicolons are mandatory (but, OTOH, allows trailing commas since forever).
"because they can actually save you from - maybe not for all, but for many - well avoidable bugs."
No. That is a false statement, please don't argue with fear and half-truths. Putting semi-everywhere style prevents you from making ONE mistake, not many - the one I show in the video. And even that is a dubious line of argumentation, because you can just as well put semis in front of the offending lines, so it all comes down to the fact that you have to remember to put semis correctly, so you need a linter in place to ensure that, and once you have that, the linter will catch errors in both styles. See: eslint.org/docs/rules/semi-style (semi: first)
One bonus thing I learnt from this video is (regardless of semi-colon or no-semi-colon) the importance of writing the "return" statement correctly (video 4:15) - I can't believe I didn't know this!
For the past 6 months I've worked without them, not sure I could turn back now.
Either way, understanding how ASI works is more important than personal preference. Great video!
You've made an educated insightful video on the issue. So it definitely adds to the discussion.
Thank you.
Thank you, great video (only that last part, really)! People usually love to discuss unimportant matters and forget that what is important is to make things work. All the people that is commenting about the semicolon use or not didn't get the video, I would dare to conclude.
Thank you for your videos. I like the concept of we don't need to type semicolons on Golang, Swift. But I had forgotten that JS supports it. I have removed all of the semicolons in my current project, luckily, VS Code and TypeScript can detect 2 errors due to the edge case that you told us in the video.
The only time I use semicolons are after assignment and using ESLint to catch the couple use cases you mentioned, which I rarely run into because I use Array.from anyway when looping through dom stuff. One strange case that produces an error is when using a function expression followed by an iife that returns something:
var five = function() {
return 5
}
(function(){
var bs = "bs"
return bs
})()
If you put the parenthesis inside the iife, though, such as this, it works fine:
(function(){
var bs = "bs"
return bs
}()) //
As a solution architect and freelance developer - I code Javascript and PHP alot, since they have very similar syntax, it makes thinking about or around them a little less work.
Actually, it is possible to "Deactivate ASI". Quotes for not really. Still, I run my Node code with JSHint, as in:
> jshint server.js && node server.js
This way, the node command is only executed if the JSHint has no errors, and missing semicolon is considered an error by JSHint by default. Aka, it will just prompt a missing semicolon error and not execute the js files.
in languages that don't require them, I get always errors for put them... they are like "my logical end character" and I put them almost without thinking...
Brackets are also something hard for me to leave out...
The important part is to be able to read the code and abstract its functionality, that way things like the return example can be noticed and fix...
Another case is a line starting with + or -, but I can’t think of such a line that would appear by accident, unless you’re doing horrible things with valueOf or something. The problem with ASI is that it sometimes inserts more semicolons than it should; trying to solve that by adding semicolons is like trying to extinguish a fire with gas…
Love this video! From my perspective, if you prefer the looks of your syntax using semi-colons, or if it makes it easier for you to context-switch between languages, by all means, use semi-colons. However, as MPJ says, you cannot make a logical argument that you _should_ use them. I don't use them because in my book it's one small thing that I can save time on - and the accumulated amount of time you can save can actually be significant over the span of years.
how come i cant subscribe twice :(
i feel the need!!!
We will call those people ... "wrong" :D
8:18 I just got this tattooed on my forehead. Productivity in my team went up by 50%
Right on, Captain! Very well illustrated.
There is one reason I can think of to use semicolons: whenever I ask someone to look at JS code I need help with, I first get a 10 minute tirade on 'why you need to use semicolons!' before I can even begin to explain my problem. :D
On a side note, in the early stages of programming when jumping between PHP and JS, no semicolons can be a super quick visual queue on which language one is looking at at that moment.
Heh, yeah. Going against the mainstream always comes with a certain inertia in all areas. The problem is that if one habitually capitulates to that, it leads to stagnation.
Personally, I use semi-colons because the code will eventually be minified. In node it's not an issue, but then it helps simply for consistency.
+Robert Ferentz Hi Robert! Glad to have you on the show. Unfortunately, a well-meaning but misinformed individual has been has been telling you another lie. Code without semicolons minifies just fine. Closure compiler, yuicompressor, packer, and jsmin all can properly minify it. More reading can be found here: blog.izs.me/post/2353458699/an-open-letter-to-javascript-leaders-regarding
Let's continue to comment on mpjme's videos to use semicolons just for fun , so we can have a semicolon video number two :)
+Pranay Kotapi I CAN MEAKE SEMICOLAN VIDEOS ALL DAY
OH YUEAH?
I CON WOATCH THEM OL DAY!
Btw, I learned about your channel just this morning. I've watched most of your videos already. Do you have a facebook page where I can follow you? :)
lets count all omitted semicola and post it. first up gets a lollypop
Man I thought I was going crazy, but I really am hearing Jingle Bells REALLY quiet in my left ear. Good video either way :)
I hope you make a video about call and apply, the point of them, and examples of when they are super useful. THAT WOULD BE AWWWEESSSOOMMEE. Happy New Year :D
1:00 "Best practice - that's what you and your team decide is best practice."
Whoa! Totally depends on the team!
Best case: Team members have lots of experience and *know* why they chose what they chose.
Worst case: Team members have not so much experience and just stick with what they falsely think is good.
At AFAS, we do use semicolons and we have a linter (which also runs during continuous integration). The linter is configured to report ‘missing semicolons’. This way, we are immune to ASI bugs as far as I can tell.
Nope. That is the point of this video. A linter cannot detect ASI bugs.
+mpjme (It can detect one specific type of ASI bug, but only that one.)
I have configured eslint for mandatory semicolons. I experimented with several asi bugs, but all of them are flagged by eslint. I have set up a workspace at ide.c9.io/johan-gorter/semicolons
Lines starting with plus and minus (+, -) will also get you in trouble.
+Mustafa Enes Is that actually a real-life concern though? Have you had this problem ever? If so, could you please demonstrate?
Concatenating JavaScript files is another that I know of that I omitted from the video because I didn't find it to be a real-word concern. The only valid reason for concatenating js is to build some kind of javascript bundler or parser, and in that case is just crazy to assume that the code is written in a certain way. That kind of code needs to handle all valid JavaScript.
+mpjme If you happen to implicitly coerce types, using plus in front of a value (i.e.: from string to number), and if the expression is placed in the beginning of a line, this happens. I know it doesn't sound like real life but I know it's real life because it has happened to me. Could look like this (not the actual code that I had to deal with):
function lorem () { console.log('lorem') }
function ipsum () { console.log('ipsum') }
function getMyStringValue() { return '5' }
var foo = getMyStringValue()
+foo > 10 ? lorem() : ipsum()
console.log('foo:', foo)
this makes `foo` undefined which essentially is a hard-to-debug-bug. I agree you when you say it's mostly about the lines starting with `[` and `(`, it's totally legit, but there may be times when some unimaginable situation causes mess. So being always aware of what starts a line should just avoid these creeps.
BTW I'm watching your videos with joy. Your presentation and tone is just great.
Here's another situation (not involving a line beginning with parentheses or square brackets) where using semicolons will, if not completely save you from ASI errors, at least make them less damaging:
Say foo is a function that has side effects and returns a value. Our code (inside a larger function) is:
if (bar) return
foo()
//Do more stuff.
If you really meant return foo(), using semicolons elsewhere won't prevent it from returning undefined if bar is truthy. However, it will mean that whoever's debugging the code will have a pretty good idea that it was supposed to return foo(), whereas if you never use semicolons it's not at all clear what the intended behavior is (is foo supposed to be called to give a return value, or as the first line to be run if bar was falsy).
+Yitzhak Kornbluth can you explain more how intent would be clearer? I don't quite see it. Let's say our linter has standardjs settings and the above code is what is checked in. Now, let's assume the same mistake was made with a semicolon linter:
if (bar) return;
foo();
To me, the intent is not clearer. I can only assume that you are referring to a team that doesn't use a linter and has mixed semicolon and semicolon-free because they have no automated checks for it, in which case I'd argue that the team has bigger problems and it's like straightening the tie of a person not wearing any pants.
I think a better example would be a semicolon linter that, in ambiguous cases like that, will flag it rather than autocorrecting it to match what JS does. (I was originally thinking of without a linter, but such a linter would make the gains even more pronounced. In other words, when using a linter that flags places where ASI may have unanticipated effects, using semicolons allows it to be somewhat more discerning about when those effects are unintended.)
I use semicolons as at work I'm context switching between js and php but I don't think it matters either way aslong as the code executes
I actually agree and disagree. I ran into a problem when the mobile web came up. Back then, I did not minify the code and everything worked fine on desktops. Then Mobile web came up and some German Providers minified (and removed all breaks) the code before they send it to the client, so they send less data.
So:
a=1
b=2
c=3
turned into
a=1b=2c=3
(took me a while to understand why so many people had a problem all of the sudden)
That's the other way around and a semicolon fixed my issue.
But I agree, that using semicolons strictly, will safe you from everything.
Great channel btw! I really like your work!
for me it's about consistency. IE: the only way to save you from a error caused by a line starting with ( or [ is by using semicolons. the moment you only use semicolons on the line after that, you have code that you have to work around and constantly remind yourself and your team to add a semicolon after that line. and that's dumb... like automatic semicolon insertion....
As long as you're not one of those idiots who puts semi colons at the end of lines in Python.
It's worse when a Python tutorial does it. I haven't seen them in a while, but it's just weird
I use semicolons because I like being open for those weird edge cases.
But when you mentioned the common objection, I was thinking the same answer. Still, I better not catch anyone omitting semicolons on my projects. ;)
What do you think about using semicolons for clarity? I don't necessarily use them because I have to, in the sense that you don't "have" to use curly braces around if/for/while statements/loops
Thx for the clarification on where forgetting a semicolon will bite you.
This video isn't in the playlist for some reason
Going to link this video anytime someone starts a semicolon argument with me. Thanks!
Well done! I always just took semicolons for granted, which of course, you shouldn't.
In the app my development team uses, we use IIFEs everywhere. As a result, if we don't use semicolons, tons of errors like the ones you described at the end would happen. Now, we could do what some people do and insert a semicolon at the *beginning* of any line that starts with an IIFE, but semicolons at the start of a line? Come on, that should bug anyone who's coded in any language other than JS in their life.
Your errors would not occur due to style, it would occur because you don't use ESLint, which easily catches these errors with (eslint.org/docs/rules/no-unexpected-multiline). You should of course be using ESLint anyway, because this error can occur whenever someone forgets a semicolon. You keep falling into the mind trap that a semicolon-style coding turns the ASI off - it's always there, regardless of style. Nothing wrong with semi, nothing wrong with no-semi, but if you say that one leads to higher quality than the other, you are deluding yourself.
Semicolons at the beginning of an IIFE is common and perfectly practice and if it bothers you then it's breathing exercises and a more open mindset you need. :)
Thank you for your video! I was unsure about this! I was wondering if you could make a video about pseudo coding, what it is and how you personally use it.
Again, thank you for your awesome videos!
I am still a beginner in JS and learned to type it without semicolons. Just done some practice with IIFEs and it can be a problem.
const firstName = 'John';
(function(name) {
console.log(name);
}(firstName))
Without the semicolon JS thinks I am declaring a function and get a type error.
Yes. When you are doing semicolon-less style, you need to prefix lines that start with ( with a semicolon:
;(function(name) {
console.log(name);
}(firstName))
8:20 - I wish my coworkers understand that!
thanks, bro the video was so helpful
Semicolons are not there for the parser, they're there for the reader. Without them, I have to read down to the beginning of the next line to determine when the current statement has ended, since some statements are broken into multiple lines. Semicolons make it clear where a statement has ended, so my eyes don't have to scan as much code to read a single statement. The expense of a single additional character at the end of the line is minimal to nonexistent since I don't "read" semicolons, I simply scan for their presence.
I understand, but due to ASI, you, as a reader, cannot use the semicolons to determine where a statement ends. The approach you describe works great in other languages that doesn’t have ASI, but unfortunately we have it in JavaScript.
I think perhaps you misunderstood my point.
I understand that, due to ASI, we cannot technically assert with 100% confidence that a semicolon is the definitive end of a statement. For example, I too have been burned by this situation:
return
{
unreachableObject: true
};
which becomes:
return;
{
unreachableObject: true
};
In this case, my intent was that the semicolon marked the end of the statement but due to ASI this turns out not to be the case.
The point I was trying to make in my original post is that a POLICY of using semicolons can COMMUNICATE the end of a statement IN VIRTUALLY ALL CASES, and in most cases doing this saves the reader time.
I'll illustrate why with an example. Consider this code:
function foo()
{
longVariableNameThatGoesToTheEndOfTheLine.longMethodNameThatIsLong()
.somethingElse()
longVariableNameThatGoesToTheEndOfTheLine.longMethodNameThatIsAlsoLong()
.somethingElse() // oops forgot to indent correctly
longVariableNameThatGoesToTheEndOfTheLine.longMethodNameThatIsLong()
longVariableNameThatGoesToTheEndOfTheLine.longMethodNameThatIsAlsoLong()
.compoundOperationWithAReallyReallyLongNameThatGoesForever()
.addAnother()
longVariableNameThatGoesToTheEndOfTheLine.longMethodNameThatIsAlsoLong()
longVariableNameThatGoesToTheEndOfTheLine.longMethodNameThatIsLong()
+ 5
longVariableNameThatGoesToTheEndOfTheLine.longMethodNameThatIsAlsoLong()
longVariableNameThatGoesToTheEndOfTheLine.longMethodNameThatIsLong()
var longVariableNameThatGoesOnForALongWaysAcrossTheScreen = longVariableName => longVariableName * 3
+ 2 // oops accidentally viewed file in editor with line wrap so indentation here is off
}
Without semicolons, if I want to parse this into distinct statements I have to scan each line, then down to the beginning of the next line to see if the previous line has ended. This simple example does't take that long, but it requires me to both scan one line and also interpret the semantics of the next line to determine if it constitutes the beginning of a new statement or the continuation of the previous one (unless I'm lucky and I can rely on 100% accurate indentation). Furthermore, I constantly find myself having to look to the next line to determine whether I'm looking at the totality of a statement, since the statement itself no longer contains its own delimiter. With semicolons, the process of parsing that code into a series of statements takes me a few seconds less and all I'm doing is scanning from the right side of the margin. This allows me to scan over the code without reading any detail, which in my mind is a good way to separate concerns.
You could make the same argument about new lines, really. They aren't technically necessary, but I'm sure your viewers would agree they are appreciated :)
Anyway, I'm not trying to change your mind, just sharing my perspective. By now I have probably given the impression I'm some kind of semicolon nazi, which I am not. The semicolon issue is nowhere near as critical as the question of whether opening braces should appear on their own line, which naturally they should (don't @ me).
Thanks for the reply and for all your great videos!
Thank you for making the point I came here to make.
Saves me much typing :)
But that brace style... blasphemy!
I look at it this way.............. ..........
this video is great, but i miss your functional programming series. Can you do more videos like that? e.g. for react.js, flux, etc.
Doesn't this crush Crockfords arguments against omitting semicolons? It would be interesting to hear his reply.
MrAzulay 5 years old, but look at this thread on Bootstrap's Project and Crockford's opinion about semicolons in a particular case: github.com/twbs/bootstrap/issues/3057
Hey! Does something similar exist for commas in JavaScript??
I mean, outside of separating array elements, object properties, and function parameters, commas seem equally unnecessary as long as statements are separated with new line characters (line breaks)!
Can anyone confirm?
Just a quick addendum: Commas are also necessary in cases where a variable is declared/initialized but not assigned -- unless it's the first variable to be declared/initialized (i.e., coming right after the let or const keyword).
Other than those cases, commas too are unnecessary in JS.
Confirm?
Amen, brother!
I totally agree with your (@mpjme) last statement that one should think about the value of a comment.
... but the result from all those comments where that you made this video, which is a great handout every time one has this nasty semicolons discussion. So this time, thanks to those comments we got this great video :-)
I don't know if this comment has value for you but it's just to tell you how happy I am about this video and all the statements you put into it.
thank you, you make my week, awesome Monday :)
+Long TRAN Right back at you, your kind words make my monday mornings too!
People are generally afraid of learning new things and are segwaying from other languages...which is why they are so passionate about their semicolons. They see it as a threat to their desire/plan not to have to learn something new. They hope to leverage all their years of experience in other languages and perhaps this places them back at the starting line with everyone else - this apparent loss of advantage is no doubt unsettling.
....that's my opinion
After watching this over a year ago... I care not what people use...but why are parameters in for loops separated with semicolons and not commas...that is the one that was always so irritating...
It's funny, back when this video came out I was definitely in the semicolons-must-be-everywhere camp. Since then, it seems that I've gone the complete opposite direction. Now using the Standard Style Guide (github.com/feross/standard) and omitting semicolons where possible. I feel like my code has been let free and is more beautiful now :D
Where I work we use semicolons just because most of us also write PHP (you know, the whole "instruction separation" concept that also exists in C). But yeah, this JavaScript "semicolons or die" mentality is really pointless.
Great show, great logo! Peace .)
return {
result: "This will succeed"
};
return
{
result: "this will fail"
}
return
}
result: "This will also not do what you want it to do"
};
You could put semicolons all throughout that code and it will still fail. The problem isn't the semicolon; the problem is having a return on a line by itself. I'm not sure if you are criticizing omitting semicolons or not, but if you are, MPJ addressed this in the video.
stop programming
8:20 - if only people would take this advice....
I use to develop in Pascal/Delphi so the lack of semicolons doesn't really bother me.
I think the reason that people are commenting on it is that you're the first person I've ever seen that deliberately omit them.
It's so commonly used in almost every language that watching someone omitting them just looks weird.
Dude, many people omit semicolons you know. Even npm is written without semicolons.
Someone needs to see a video called "What programming IS NOT about"
so you suggest to leave semikolons, but on certain places we must use them? that is weird. I code PHP too. PHP shows a syntax error due to leaving semikcolon. semicolons help me to see the structure of the code. Iget a good feeling each tme I type a semicolon. It means: one step more done. got to deal with it since you re doing a great job. thanks
+DaddyChronic as I clearly say in the beginning of the episode, I'm not recommending (or the opposite) - I'm just trying to get you to think on your own instead of blindly swallowing what many authorities are trying to tell you is "the right way". I'm just saying that you can if you want and there is nothing wrong with it. I made this video because I found that a lot of people are saying that there is a "right" way with semicolons and I wanted to provide a counterpoint to that.
But back to your question, yes, there is one case where you still have to put a semicolon if you do not put them on every line. I don't agree that this is weird, there are plenty of programming constructs that we use only in certain places for certain cases. I also *strongly* disagree that it's one more step to get thing to get things done, considering that the alternative is to put them on EVERY line when they have no function at all on all other lines. It's just busywork.
@mpmje I'm guessing that @7lions is for semicolons always but for presentational / personal taste rather than ASI beliefs which have been well debunked. Great video. I only recently even heard of ASI. Haha. But like said in the comments - BSD vs one-true brace?
While I agree that no semicolons could be fine in ES5 and older, because you don't really run into the code you mentioned (that array would be stored inside variable so new line wouldn't start with "[" but with variable name).
But with ES6 things are going to change because
[a, b] = something();
is a valid destructuring construction.
Isn't it strange to write
{ a, b } = something()
;[a, b] = something()
thus making code less uniform, if you can make it more uniform by just writing semicolons?
{ a, b } = something();
[a, b] = something();
And it could get worse with ES7 and beyond. Using semicolons is just more future proof. Also I disagree with the statement that these errors are easy to catch. I don't really think that the 'more readable code' is worth the trade-off for the disadvantages.
+Petr Huřťák Again, dude, I'm not saying that you shouldn't use them, or that they don't protect from this case. That's not the point of the video. The point of the video is to dispell the religion that adding semicolons helps in general. They only help against this case.
You are smart and funny, love your videos!
I only use semi-colons because i've been coding alot in C++ and C# before learning Javascript so my hand adds them automatically xD
Semicolons are required in JS. ASI is an error-correction tool. If you leave off a semicolon, ASI will fix your mistake. This is not the same as semicolons being optional. Saying "inserting semicolons doesn't solve the issue of ASI" is like saying "spelling words correctly in your texts doesn't solve the issue of auto-correct."
That is one way of viewing it. There is no one true way on this matter. The way I view it is that ASI shouldn't have been put in the language in the first place, but now that it is, I find the semi-less style much natural to me, in line with how the language works. Putting semicolons there feels wrong to me as it's work that the computer will do for me - sort of like manually clearing memory in a garbage collected language.
I think auto-correct is a little problematic analogy - I think maybe pronouns are a better one - humans "fill in" pronouns and sometimes there are ambiguity when you construct a sentence poorly. Mattias and Chris do not stop using pronouns because of this, Programmers like Mattias and Chris become better at constructing our sentences.
Analogies don't work, really. 😂
@@funfunfunction Yeah maybe not the best analogy.
Makes me wonder how many of the semi-colinites are all new students of JS and their instructor (s) pushed them on them. (Like mine, but I'm a rebel and don't always take what teachers say as canon. I once got into an argument with my teacher in 3rd grade when I suggested the continents on the map must have been connected at one time. Guess who ended up being right.)..
Thanks
What was actually happening there?
The only true solution to ASI is using an autoformatter. So whether you want semicolons or want to avoid them, just use prettier and let it format on save. It's also a great way to get rid of having opinions about code style. Prettier has opinions about code style so you don't have to.
Nope, an autoformatter does not solve ASI for you. Prettier is great, but it has nothing to do with ASI. I made a quick example:
prettier.io/playground/#N4Igxg9gdgLgprEAuc0DOMAEAPTBeTACgEp8A+TYAHSk0wCc4YBXe2muqmKkACzgA2AiDwDcNAL40a2EtKiES5ShwZNW7EGggBbJrwCWUAOY9JxEiAA0ICAAcYB9MlABDevQgB3AAruEaMggrgBuEAYAJtYgAEb0rmAA1kwAynYJRsbIMPTMcDZGaHD0MD7xxjquyABmrgJFNgBWaNgAQvFJqa56ADJGcDV1DSDp9EX0QTGuMQCewlDRdvRGMADqkTC8yAAcAAw2SxBFq-F2QUtw4yEDNowAjswGjGWuFVVItfX5WnA6Btm5b5oTICOAARWYEHggy+Nhg03WEU2yAATHD4gYBJkAMK6SpBKDQG4gZhFAAq00CHyGcAkEiAA
It solves ASI by making the ASI obvious. You would typically set up prettier to format on save. The next time you look at the code after saving, you'd see what's in the right side of the link you posted, which is clearly not what you had in mind. It doesn't prevent ASI but it eliminates the nasty surprises.
EDIT: To clarify, I'm using prettier and prettier has saved me from ASI mistakes in the past because I format on save and save regularly.
Aaah, because you use it on save, that's interesting. I use it on pre-push and at that point I've already caught them. I've tried using it on save but it makes me totally insane as I'm easily distracted, but that's a valid strategy for someone that can deal with on-save formatting. I'm a TDDer so that's the way I catch em'.
I actually rely on prettier as part of writing code these days. Much like how autocomplete and auto-imports help me type less, prettier helps me not obsess about formatting. Instead of re-indenting code when you add a try/catch, just add the try/catch and hit "save" and prettier formats it automatically. If there's one thing prettier has helped me with the most, it's not having too many opinions about code formatting -- I used to really obsess with making the code look nice, now I just let prettier make those decisions for me.
I love the xkcd reference :)
imgur.com/csEUdBa
My cat was very excited to listen to you in this hat. Thanks for posting, I was also puzzled how come you don't use semicolons from video one. Mystery solved.
BRAVO!
At 5:34 how would you avoid getting 'undefined' without using semi colons?
+DarkPrince304 You have to elaborate here. When would using semicolons prevent you from getting undefined?
I meant since you don't use semicolons how would you have written it to avoid getting undefined. I can see that you used semi colons in your example and then we get the output 'object Object'. How to get this output without using semicolons?
+DarkPrince304 sorry misread your comment. You either simply dont do that, when you are beginning your lines with a bracket or parents you're usually doing things to cleverly, or you BEGIN those lines with a semicolon. It's easy to set up a linter rule for either approach.
Oh, I see. Learned another valuable approach through your reply. Thanks a lot! :)
Don't you ever minify your code? If so surely you've come across situations where omitting the semicolon results in errors.
+YehThatRocks! What minier are you referrring to? All major minifiers supports this just fine. It would be very strange if they didn't too, since the spec very clearly allows omitting them. It's how the language is designed and specified.
how come i will get errors all over the place if i don't end statements, var declarations, or iife with semicolons?!
+/ while it is perfectly valid JavaScript to omit semicolons, the environment that you are using for development might be set up to enforce certain code conventions using a tool called a linter. The most used linter nowadays is called eslint. It can be configured with many different settings, such as enforcing semicolons (or disallowing them), or making use you use spaces or tabs in a certain way. The use of a linter is common in workplaces so that everyone uses the same conventions - many people disagree on how to write code most most people agree that mixing conventions is bad inside a single codebase.
funfunfunction on my latest project all i've been using is notepad++ and chrome. i have yet to test anything under different circumstances because i only recently (just the other day in fact) stopped using semi colons at the end of functions, loops, and conditional statements. i'm not even sure if i have deliberately tested it yet, although i often seem to run into errors if i forget a semi colon after certain code. i used to put a semi colon at the end of every piece of code just because i ran into so many errors by accidentally omitting semi colons when i first started learning javascript. however, i'm pretty sure i read on w3s that var declarations and statements require semi colons? idk
+/ no, semicolons are not required in JavaScript. There is only one error that you save yourself from by adding semicolons in every line, and it's the one I talk about in the video. If you feel that you're getting more errors when you omit semicolons, that's an illusion.
funfunfunction saweet. well, then, time to stop using semi colons!!!
If you use a linter thoe, you may get warnings. Also if you have set up rules for sonar you may get warnings.
4:04
You misunderstand... I don't want to get rid of it, I want to appease it. And appease my linter in the process - and appease the next coder that has to look at my code.
doesn't "use strict"; prevent ASI?
+Noah Loomans no.
Monday Morning GMT Time. Accuracy. lol!
If your team is going to roll without semicolons, then you need to being using jshint and can all pass the asi.qfox.nl/ test
+Derek Eskens Again, you're just spreading misinformation here dude. You're implying here that semicolons adds a protection that it does not. It does not reduce the need for a linter, and it does not reduce the need to know how the ASI works. Using semicolons does not save you from this.
Best practice for Javascript depends on the browser... FOIL
(Here comes another big hairy but) BUT With the increasing (and justified) usage of minified code in production, ASI won't do the trick anymore. At the end of the day, we still need to manually put semicolons.
+Anass Maddah ASI and minification works fine:
blog.izs.me/post/2353458699/an-open-letter-to-javascript-leaders-regarding
A quote: "Yes, it’s quite safe, and perfectly valid JS that every browser understands. Closure compiler, yuicompressor, packer, and jsmin all can properly minify it. There is no performance impact anywhere.
I am sorry that, instead of educating you, the leaders in this language community have given you lies and fear. That was shameful. I recommend learning how statements in JS are actually terminated (and in which cases they are not terminated), so that you can write code that you find beautiful."
Thank you for the link you provided, it answered more than a question raised by your answer.
Having just recently tried my hands at javascript (and functional in general), I kinda realize I've picked some misbeliefs and misconceptions throughout the articles, books and tutorials i'm reading. You've made my coding a little better already
Also, I love the videos you're creating ! I found myself binge-watching because of their fun and concise format. I can't wait to discover/learn all the content you're blessing us with, and see more of what's coming next !
toe may toh, toe mah doh
I use semi colons because everyone else on my team does.
How about an episode on hoisting?
4:04 lol
5 years old, but look at this thread on Bootstrap's Project and Crockford's opinion about semicolons in a particular case: github.com/twbs/bootstrap/issues/3057
It's a well known fact that Crockford stresses semicolons, but I'm not sure why you link to this issue in particular, because it's not a particularly good champion for the semicolons-everywhere position. He's right that it's pretty silly code, but that doesn't change that it's VALID code and it seems reasonable to expect that a minifier should work on all valid JavaScript code, regardless of your opinions of that code. This is WHY we have standards. I'm not sure where we stand on the TC39 thing, but that code is still running fine in the latest version of node for me, 5 years later.
I also feel that framing this as a semicolon issue is kind of misleading - the problem here is that we're using the ! operator for something it was not designed to do. The correct way to improve this code is not by adding a semicolon, it's using an if statement:
clearMenus()
if (!isActive) $parent.toggleClass('open')
The above would also be the appropriate way to do things even if you were using semicolons.
I'm also surprised about Crockfords communication style. Imagine how most people would view the first comment if it did not have Crockfords name on it? I would think that the author was 16-17 years old. I'm surprised that the same person that wrote JavaScript: The Good Parts wrote these flippant comments, and does not hold his communication style to a higher standard.
I looked into this and found that Crockford eventually did fix it, actually:
github.com/douglascrockford/JSMin/commit/5ca277ea452beae1c25db3bc0ef5c81309a3daf4#jsmin.c
I agree with you 100%, Crockford looks like a teenager hater.
I just shared this thread because it has interesting points of view about semicolons in the comments.
Hrm...I don't agree that it doesn't matter, even though technically it doesn't because the ASI is dumb.
This turned out long, so I apologize ahead of time before you dive into my full response.
I'm not attached to semicolons in general. Python is my favorite language, but I love how I don't need semicolons because the language was designed to explicitly not use them. Javascript was clearly designed to have semicolons, otherwise ASI would not even exist.
Adding semicolons at the end of your logical lines of code will make debugging spacing/line problems easier, particularly in cases like your "return 4" example. Even if it's only slight, you'll at least always know your problem isn't a missing semicolon because you have to combat your, *ahem*, "bad behavior." And, as a bonus, you'll never run into the problem of not having a semicolon before a parenthesis or square bracket.
True, there is no central authority insisting that semicolon use be best practice, and ASI makes it technically optional in most cases, but I think there's a lot to say about readabiliity and reliability and debugging clarity when it comes to defending the insistence on always using semicolons.
Debating over how to utilize white space in languages where many differing uses of white space literally makes no difference...that debate is a bit silly, I'll admit, though the "whitespace nazi" inside me doesn't entirely feel this way.
But debating on whether or not to terminate statements with the character recognized by the language's interpreters as a statement terminator? That seems like a totally valid and reasonable debate to have, and I feel pretty strongly that insisting on always using them is a strong foundation to stand on, and while I get where you're coming from when you say it ultimately doesn't matter, I don't think you're correct since there are circumstances where you HAVE to have a semicolon, while there are no situations where you need to NOT have a semicolon where one should be.
+Dan Scannell you state that having semicolons makes debugging easier but you do not provide any actual elaboration as to why that would be.
But I did. I said that, at the very least, you would know that your issue isn't a missing semicolon, and that helps narrow down your possible syntax problems. I also qualified that by saying it may only be slightly easier, haha.
Thanks for the response!
Can you provide an example of that? Or are you referring to the issue in the video, beginning the line with a parens?
If only ASI actually worked. Good luck running this code without semicolons.
const obj = { "a": "b"}
(function() {
console.log("blah")
})();
In semiless style you prepend lines with [,(, or ‘ with a semicolon. It is the only caveat with the semiless style, but since it's the only one it's easy to remember. You can also enforce it automatically with beforeStatementContinuationChars in eslint
Dude, you're missing one thing.
function a{
return
4;
}
Any linter will say there's a semicolon missing in this example, so there's no way you won't spot an error. But if you decide not to use semicolons then no linter will help you.
+igor1043k This is incorrect. I just tried your example in eshint and it detects unreachable code just fine in this:
function a() {
return
4
}
I ran this command:
"eslint --rule 'no-unreachable:1' thecodeabove.js"
and got this:
3:5 warning Found unexpected statement after a return no-unreachable
+mpjme I don't have much experience with eslint. Good to know that it's that clever. Then my argument is outdated :)
I wonder if eslint detects the object-array example that you mentioned in the video.
I don't see how it would, really. I'm pretty sure semicolons actually do protect you in that case. But you can check out the full ruleset here, it's cool to look at either way:
eslint.org/docs/rules/
Why don't you use semicolons? Don't you know that you should always use semicolons?
You've really made alot of sense though twitter.com/codefingers
I disagree with the message that you're conveying. If using semi colons saves you from situations like the ones you mentioned (there could even be more..) and using no semicolons has no practical advantage, why should anyone not use semicolons ?
+Ricardo Matias What message is it that you think I'm conveying? Because it sounds like you're arguing against something that I do not say in the video.
you like to omit semicolons, I like to vomit semicolons