If you consider the comma as a separator, you use a comma between two items of a sequence to separate them, if you consider it as a delimiter, you put it after each item to indicate where an item ends. See the examples below:
Comma as a separator
var myCars = ["Saab", "Volvo", "BMW" ];
Comma as a delimiter
var myCars = ["Saab", "Volvo", "BMW", ];
I think the video says that you can think of commas both as separators and delimiters because both array examples above are valid. On the other hand in Javascript you can only use the comma as a separator in the parameter list of a function, e.g.
foo(a, b, c) // separator, OK
is valid whereas
foo(a, b, c,) // delimiter, NOT OK!
is not valid.
EDIT
As far as I understand, according to the wikipedia page a separator is a special case of a delimiter, namely one that is put between the different text regions whose boundaries need to be marked. In fact, the wikipedia page names comma-separated values as an example use of delimiters.
So, in general you can use delimiters in different ways: before, after, on both sides of the portion of text to be marked.
The reason why I interpreted delimiter as "marker that is put after an item" in the Javascript context was motivated by the array literal example, which is valid also for C, C++, and Java (I think I have seen at least one question on stack overflow regarding this topic).
Another example of similar but different use of a character is that of semicolon as a statement delimiter (C, C++, Java, Ada, ...) and as a statement separator (Pascal). Therefore
if (a > 0)
printf("Positive\n");
else
printf("Non positive\n");
is correct C code whereas
IF a > 0 THEN
WriteLn('Positive'); (* Syntax error here! *)
ELSE
WriteLn('Non positive');
is no correct Pascal code.
Maybe terminator would be a better / less ambiguous term than delimiter?
E.g. one could formulate the quote as follows: "Some people get confused about how commas work. They think they should be item terminators rather than item separators. Now (in many cases) you can think about them either way."
The brace at the end of the line is the ancient K&R C standard, from Brian Kernighan and Dennis Ritchie's book The C Programming Language, which they published in 1978 after co-inventing the UNIX operating system and the C programming language (C was mostly designed by Ritchie, based on B, which another Bell employee Ken Thompson had adapted from the older BCPL programming language), at AT&T.
There used to be flame wars about "the one true brace style."
So Ritchie created the C language, and Kernighan wrote the first tutorial, when computer displays only showed a few lines of text. In fact, UNICS (later UNIX) development started on a DEC PDP-7, which used a typewriter, printer and paper tape for a user interface. UNIX and C were finished on the PDP-11, with 24-line text terminals. So vertical space was indeed at a premium. We all have slightly better displays and higher resolution printers today, right? I mean, I don't know about you, but I have three 24" 1080p displays in front of me right now. :-)
Also, so much of that little book The C Programming Language is code samples that putting the braces at the ends of the lines instead of on their own lines allegedly saved an appreciable amount of money on printing.
What is truly important is consistency throughout a project, or at least within a given source code file.
There are also scientific studies showing that the brace on its own line (indented to the same level as the code, in fact) improves code comprehension despite what people think they think of the aesthetics. It makes it very clear to the reader, visually and instinctively, which code runs in which context.
if( true )
{
// do some stuff
}
C# has always supported evaluating a single command after a branching expression, by the way. In fact, that's the only thing it does, even now. Putting code in braces after a branching expression just makes that one command a goto (the compiler creates scope using jmp instructions). C++, Java, C# and JavaScript are all more or less based on C, with the same underlying parsing rules, for the most part. So in that sense, C# is not "based on Java."
Summing up, this is a bit of a religious/flame-war issue. But there are studies making it pretty clear that arranging code in blocks improves human comprehension. The compiler couldn't care less. But this is also related to the reason why I never put a line of code after a branch without braces--it's just too easy for me or another programmer to slap another line of code in there later and slip on the fact that it will not execute in the same context with the line right before or after it.
EDIT: Just go look at the Apple goto fail
bug for a perfect example of this exact issue, which had very serious real world consequences.
if( true )
doSomething();
becomes...
if( true )
doSomething();
doSomethingElse();
In this case, doSomethingElse()
executes every time, regardless of the outcome of the test, but because it is indented to the same level as the doSomething()
statement, it's easy to miss. This isn't really arguable; studies back this up. This is a big source of bugs introduced into source code during maintenance.
Still, I'll admit that JavaScript closure syntax looks a little silly with braces on their own lines...aesthetically. :-)
Best Answer
I've heard it's called NPM style "comma-first" rule. Example from the doc:
The doc doesn't state the motivation behind this coding style, but I guess it's to prevent dumb syntax errors from placing an excessive comma at the end of a comma-separated list, and to alleviate the mental tax it places on you from trying to get that part of the syntax right.
Also note that NPM style recommends "not to use semicolons". If you adopt this style, you're also doing away with the semicolon that fills the final position of a var statement, making it tempting to place a comma there instead.
As for the JSHint error, there's a switch to allow comma-first style line breaks.