[gjs: 41/43] docs: Update Style_Guide.md



commit e499d7461c3a5b2cc2375aa5105651aea25dff04
Author: Philip Chimento <philip chimento gmail com>
Date:   Sun Aug 4 16:58:58 2019 -0700

    docs: Update Style_Guide.md
    
    The coding style guide is by definition the .eslintrc.yml file now.
    Remove from the style guide in the documentation all rules that are
    already enforced by eslint, as well as a few outdated conventions.

 doc/Style_Guide.md | 71 +++++++++++++++++++++---------------------------------
 1 file changed, 28 insertions(+), 43 deletions(-)
---
diff --git a/doc/Style_Guide.md b/doc/Style_Guide.md
index 6f23e9b7..908fefc3 100644
--- a/doc/Style_Guide.md
+++ b/doc/Style_Guide.md
@@ -4,15 +4,22 @@ Our goal is to have all JavaScript code in GNOME follow a consistent style. In a
 JavaScript, it is essential to be rigorous about style (and unit tests), or you rapidly end up
 with a spaghetti-code mess.
 
-## Semicolons ##
+## Linter ##
 
-JavaScript allows omitting semicolons at the end of lines, but don't. Always end
-statements with a semicolon.
+GJS includes an eslint configuration file, `.eslintrc.yml`.
+There is an additional one that applies to test code in
+`installed-tests/js/.eslintrc.yml`.
+We recommend using this for your project, with any modifications you
+need that are particular to your project.
 
-## js2-mode ##
+In most editors you can set up eslint to run on your code as you type.
+Or you can set it up as a git commit hook.
+In any case if you contribute code to GJS, eslint will check the code in
+your merge request.
 
-If using Emacs, try js2-mode. It functions as a "lint" by highlighting missing semicolons
-and the like.
+The style guide for JS code in GJS is, by definition, the eslint config
+file.
+This file only contains conventions that the linter can't catch.
 
 ## Imports ##
 
@@ -25,7 +32,11 @@ const {GLib} = imports.gi;
 
 ## Variable declaration ##
 
-Always use one of `const`, `var`, or `let` when defining a variable. Always use `let` when block scope is 
intended; in particular, inside `for()` and `while()` loops, `let` is almost always correct.
+Always use `const` or `let` when block scope is intended.
+In almost all cases `const` is correct if you don't reassign the
+variable, and otherwise `let`.
+In general `var` is only needed for variables that you are exporting
+from a module.
 
 ```js
 // Iterating over an array
@@ -38,13 +49,14 @@ for (let prop in someobj) {
 }
 ```
 
-If you don't use `let` then the variable is added to function scope, not the for loop block scope.
+If you don't use `let` or `const` then the variable is added to function
+scope, not the for loop block scope.
 See [What's new in JavaScript 1.7][1]
 
 A common case where this matters is when you have a closure inside a loop:
 ```js
 for (let i = 0; i < 10; ++i) {
-    GLib.idle_add(GLib.PRIORITY_DEFAULT_IDLE, function() {
+    GLib.idle_add(GLib.PRIORITY_DEFAULT_IDLE, function () {
         log(`number is: ${i}`);
     });
 }
@@ -52,20 +64,18 @@ for (let i = 0; i < 10; ++i) {
 
 If you used `var` instead of `let` it would print "10" a bunch of times.
 
-Inside functions, `let` is always correct instead of `var` as far as we know. `var` is useful when you want 
to add something to the `with()` object, though... in particular we think you need `var` to define module 
variables, since our module system loads modules with the equivalent of `with (moduleObject)`
-
 ## `this` in closures ##
 
 `this` will not be captured in a closure; `this` is relative to how the closure is invoked, not to
 the value of this where the closure is created, because `this` is a keyword with a value passed
 in at function invocation time, it is not a variable that can be captured in closures.
 
-To solve this, use `Function.bind()`, or fat arrow functions, e.g.:
+To solve this, use `Function.bind()`, or arrow functions, e.g.:
 
 ```js
-let closure = function() { this._fnorbate() }.bind(this);
+const closure = () => { this._fnorbate(); };
 // or
-let closure = () => { this._fnorbate(); };
+const closure = function() { this._fnorbate() }.bind(this);
 ```
 
 A more realistic example would be connecting to a signal on a
@@ -87,13 +97,13 @@ const MyPrototype = {
 
 JavaScript allows equivalently:
 ```js
-foo = {'bar': 42};
-foo = {bar: 42};
+const foo = {'bar': 42};
+const foo = {bar: 42};
 ```
 and
 ```js
-var b = foo['bar'];
-var b = foo.bar;
+const b = foo['bar'];
+const b = foo.bar;
 ```
 
 If your usage of an object is like an object, then you're defining "member variables." For member variables, 
use the no-quotes no-brackets syntax, that is, `{bar: 42}` and `foo.bar`.
@@ -107,30 +117,5 @@ If your usage of an object is like a hash table (and thus conceptually the keys
 - True global variables (in the global or 'window' object) should be avoided whenever possible. If you do 
create them, the variable name should have a namespace in it, like `BigFoo`
 - When you assign a module to an alias to avoid typing `imports.foo.bar` all the time, the alias should be 
`const TitleCase` so `const Bar = imports.foo.bar;`
 - If you need to name a variable something weird to avoid a namespace collision, add a trailing `_` (not 
leading, leading `_` means private).
-- For GObject constructors, always use the `lowerCamelCase` style for property names instead of dashes or 
underscores.
-
-## Whitespace ##
-
-* 4-space indentation (the Java style)
-* No trailing whitespace.
-* No tabs.
-* If you `chmod +x .git/hooks/pre-commit` it will not let you commit with messed-up whitespace (well, it 
doesn't catch tabs. turn off tabs in your text editor.)
-
-## JavaScript attributes ##
-
-Don't use the getter/setter syntax when getting and setting has side effects, that is, the code:
-```js
-foo.bar = 10;
-```
-should not do anything other than save "10" as a property of `foo`. It's obfuscated otherwise; if the 
setting has side effects, it's better if it looks like a method.
-
-In practice this means the only use of attributes is to create read-only properties:
-```js
-get bar() {
-    return this._bar;
-}
-```
-
-If the property requires a setter, or if getting it has side effects, methods are probably clearer.
 
 [1] 
http://developer.mozilla.org/en/docs/index.php?title=New_in_JavaScript_1.7&printable=yes#Block_scope_with_let


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]