Noissue - Add some more JavaScript coding guidlines

pages/coding-style.html

Index: pages/coding-style.html
diff --git a/pages/coding-style.html b/pages/coding-style.html
index 553402cd508a746e0587e41d989f54f1b2d588b0..5429e2809fffbaa042804fc9e4b403bd581836cf 100644
--- a/pages/coding-style.html
+++ b/pages/coding-style.html
@@ -25,8 +25,15 @@ title=Coding Style
 <ul>
   <li>{{s15 Follow the Mozilla Coding Style's <a href="https://developer.mozilla.org/en-US/docs/Developer_Guide/Coding_Style#JavaScript_practices">JavaScript practices</a>.}}</li>
   <li>{{s16 Opening braces of object literals in don't go on their own line when that would cause a syntax error.}}</li>
-  <li>{{s17 Use <code>bind()</code> to ensure the desired value of the <code>this</code> variable, don’t use temporary variables as a replacement.}}</li>
+  <li>{{javascript-this Use <code>bind()</code> (or arrow functions) to ensure the desired value of the <code>this</code> variable, don’t use temporary variables as a replacement.}}</li>

[Sebastian Noack, 2017/01/16 17:07:14]

For code snippets please also use the <fix> tag, see the Python section, for
reference. This makes sure they get not translated.

[Sebastian Noack, 2017/01/16 17:07:14]

I think this should go below the rule for arrow functions and clarify that you
should only use the function statement + bind() for compatibility with legacy
browsers if using arrow functions isn't an option.

[kzar, 2017/01/17 06:48:51]

Done.

[kzar, 2017/01/17 06:48:51]

Done.

   <li>{{s18 In classes, prefix private functions with a single underscore to make them pseudo-private.}}</li>
+  <li>{{javascript-let Use <code>let</code> or better yet <code>const</code> for variable definitions where possible instead of <code>var</code>.}}</li>

[Sebastian Noack, 2017/01/16 17:07:14]

I find this rule a little too vague. How about:

  If supported, use
  <a href="https://developer.mozilla.org/../Statements/let">block-scoping</a>,
  except when sharing global variables between scripts cannot be avoided.

As for const, this should could go into another rule, if we come up with any.
But keep in mind that we currently only use const for immutable types. If we
would use const wherever possible we would also have to use them for objects
which might change, as long as the variable itself isn't reassigned.

[kzar, 2017/01/17 06:48:51]

Done.

+  <li>{{javascript-arrow Use the <a href="https://developer.mozilla.org/docs/Web/JavaScript/Reference/Functions/Arrow_functions">arrow function</a> syntax for anonymous functions when the binding of <code>this</code> and <code>arguments</code> is not required.}}</li>

[Sebastian Noack, 2017/01/16 17:07:14]

Arrow functions automatically bind "this". So it seems your implications here
are the wrong way around. The reason to not use arrow functions would be because
NOT binding it would be required, right?

[kzar, 2017/01/17 06:48:51]

Well I think arrow functions simply close over the binding of `this` and
`arguments` from the parent scope, the same as functions normally do for other
variables. I think that's because they simply don't bind `this` and `arguments`
to something new like old style functions do, or am I wrong?

+  <li>{{javascript-method Use the <a href="https://developer.mozilla.org/docs/Web/JavaScript/Reference/Functions/Method_definitions">method definition</a> syntax where possible, even in preference to arrow functions.}}</li>

[Sebastian Noack, 2017/01/16 17:07:14]

I don't like how we overrule another rule here (i.e. "even in preference to
arrow functions"). Perhaps a better way to put it; "use the arrow function
syntax when passing anonymous functions" and "use the method definition
shorthand syntax when defining methods on an object". That way we have a clearer
distinction and mutually exclusive definition of the use cases, without need for
any exceptions.

[Sebastian Noack, 2017/01/16 17:07:14]

"method definition" is ambiguous as the old syntax (i.e. |{method: function() {
... }}|) arguably is a form of method definition as well. However, we a re
specifically talking about the method definition _shorthand_ syntax here.

[kzar, 2017/01/17 06:48:51]

Done.

[kzar, 2017/01/17 06:48:51]

Done.

[kzar, 2017/01/17 06:48:51]

Done.

+  <li>{{javascript-strict Where possible always use <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode">strict mode</a>.}}</li>

[Sebastian Noack, 2017/01/16 17:07:14]

Why the "where possible" restriction? Is there any legit use case for some
behavior that only exists outside of strict mode?

[kzar, 2017/01/17 06:48:51]

Done.

+  <li>{{javascript-if-else-braces When an <code>if</code>, <code>else</code> or <code>loop</code> statement spans over more than one line always enclose it with braces. When an <code>if</code> or <code>else</code> statement uses braces the other half should do too.}}</li>

[Sebastian Noack, 2017/01/16 17:07:14]

"other half" doesn't sound too technically accurrate, how about "opposing
block"?

[Sebastian Noack, 2017/01/16 17:07:14]

"loop" isn't a literal code snippet, so it shouldn't use the <code> tag. Also
"loop" is not a statement (but a group of statements).


  When an <code><fix>if</fix></code>, <code><fix>else</fix></code> or statement
  or loop spans over multiple lines ...

[kzar, 2017/01/17 06:48:51]

Done.

[kzar, 2017/01/17 06:48:52]

Done.

+  <li>{{javascript-for-of When iterating through Arrays and similar prefer <code>for (let item of array)</code> loops to traditional <code>for (let i=0; i < array.length; i++)</code> or even <code>array.forEach(...)</code> unless there is a good reason to do otherwise.}}</li>

[Sebastian Noack, 2017/01/16 17:07:14]

I think we are really only talking about arrays here, as there don't seem to be
any other objects which support both, length+indices as well as the iterator
protocol.

Also I wonder whether we can come up with a less vague rule. The only "good
reasons" to not use for..of would be if you need to either access the the loop
index, or have to iterate in non-standard order (skipping the first/last,
reversing order, etc.), or if it isn't supported by any targeted browser.

How about this:

  If supported, use for..of when iterating over arrays in canonical order,
  rather than using for(;;) or the forEach() method.

[kzar, 2017/01/17 06:48:51]

Done.

+  <li>{{javascript-object-proto Use <code>Object.create(null)</code> instead of <code>{__proto__: null}</code> and otherwise avoid the use of <code>__proto__</code>.}}</li>

[Sebastian Noack, 2017/01/16 17:07:14]

Well, by now, you should rather use Map or Set objects if you need a hash table,
rather than using Object.create(null) to avoid potential collisions.

[kzar, 2017/01/17 06:48:52]

Done.

 </ul>
 
 <h2 id="html-css">{{html-css HTML and CSS}}</h2>