You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cordova.apache.org by Apache Wiki <wi...@apache.org> on 2014/04/23 19:23:38 UTC

[Cordova Wiki] Update of "StyleGuide" by MartinGonzalez

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Cordova Wiki" for change notification.

The "StyleGuide" page has been changed by MartinGonzalez:
https://wiki.apache.org/cordova/StyleGuide?action=diff&rev1=12&rev2=13

  = Style Guide =
+ The never-ending debate, always a good source for insulting your engineering friends.
  
- The never-ending debate, always a good source for insulting your engineering friends. 
- 
- == General ==
- 
+ == General guidelines ==
+  * Each source file should include the following ''ASF Source Header''.
+  * Keep consistent and structured code.
+  * Do not use tabs, only spaces.
+  * Use 4 spaces for indentation.
+  * Remove unnecessary trailing whitespace in lines; this includes after operators, commas, semicolons or braces.
+  * Indent on top-level functions is not required.
+  * Use Linux-Unix line feed character ''ā€œ\nā€'', rather than ''ā€œ\r\nā€'' Windows carriage return.
+  * If you are editing existing code, keep the current format.
+  * Try to keep line length to 100 characters or less.
+  * Use ''lowerCamelCase ''for any variable or function. Constants should be in ''UPPER_CASE''.
+  * Minimize the usage of global variables.
+  * Avoid long comments unless necessary.
-   * trailing spaces - you should turn off "remove trailing spaces" in your editor/IDE.  That is, trailing spaces should be left in files.  Not doing this yields extra diff junk, and sometime trailing spaces are significant.
+  * trailing spaces - you should turn off "remove trailing spaces" in your editor/IDE.  That is, trailing spaces should be left in files.  Not doing this yields extra diff junk, and sometime trailing spaces are significant.
  
  == JS ==
- 
-   * four spaces '''or Brian will kill you all'''; your editor probably supports "soft tabs" which give you the UI of tabs, but actually uses spaces.  Use that, tab-lovers.
+  * four spaces '''or Brian will kill you all'''; your editor probably supports "soft tabs" which give you the UI of tabs, but actually uses spaces.  Use that, tab-lovers.
-   * brace on same line or crockford will kill you all and semicolon insertion will expeditate the catacism 
+  * brace on same line or crockford will kill you all and semicolon insertion will expeditate the catacism.
-   * single quote your string literals; it looks cleaner
+  * single quote your string literals; it looks cleaner.
-   * use literal syntax always {{{ {} [] '' }}}
+  * use literal syntax always {{{ {} [] '' .}}}
+  * Use === and !== operators rather than == and != operators.
-   * comma first makes it easier to read and catch definition bugs
+  * comma first makes it easier to read and catch definition bugs.
-   * define variables at the top of methods; they'll be hoisted there anyhow
+  * define variables at the top of methods; they'll be hoisted there anyho.
+  * Use ''forEach''( function(){ }) or regular ''for''(), instead of ''for (var t in object)''. The in operator iterates in arbitary order over all of the enumerable properties of the object, even empty properties. If you must use this syntax, use it in with the ''hasOwnProperty''('prop') statement.
+  * Use ''array = [value,  ...]'' instead of ''new Array (value, ...).''
-   * semicolons are unneccessary visual entropy, however, you must use them immediately before an opening parenthesis, square bracket or any statement which begins with an arithmetic operator token {{{ /, +, or - }}}
+  * semicolons are unneccessary visual entropy, however, you must use them immediately before an opening parenthesis, square bracket or any statement which begins with an arithmetic operator token {{{ /, +, or -}}}
  
  {{{
  var foo = { "bar":1
- 	  , "baz":2
+           , "baz":2
            }
  
  var arr = [ 1
@@ -31, +43 @@

  var my = 1
  ,   little = 2
  ,   pony = 3
- 
  }}}
- 
  == CoffeeScript ==
- 
-   * indent '''four spaces'''; note that this does not seem to be defacto standard for !CoffeeScript, yet
+  * indent '''four spaces'''; note that this does not seem to be defacto standard for !CoffeeScript, yet
  
  == Java ==
- 
-   * see [[http://wiki.eclipse.org/index.php/Development_Conventions_and_Guidelines|Eclipse Development Conventions]]
+  * see [[http://wiki.eclipse.org/index.php/Development_Conventions_and_Guidelines|Eclipse Development Conventions]]
-   * Indentation is '''four SPACES''', '''not''' ''tabs''. Please edit your Eclipse properties to update as such, by default Eclipse uses tabs.
+  * Indentation is '''four SPACES''', '''not''' ''tabs''. Please edit your Eclipse properties to update as such, by default Eclipse uses tabs.
  
  == Objective C ==
+ == C++ ==
+ == Cordova Preferences ==
+ The project has its own coding style, structure and design. Cordova components can be implemented as libraries by other applications. Because of that it is extremely important to keep a good control and flow.
  
- == C++ ==
+  * Try to return promises instead of callbacks outputs. Use '''Q '''API.
+  * Use '''superspawn''', which is a custom and extended helper class based on child_process.spawn. It provides extension resolution, quotation verification, and file verification, accepts arguments and environmental variables. __Superspawn provides promise resolution__. Located at: ''cordova-cli/src/superspawn.js''.
+  * Avoid set environmental variables (''process.env''), use '''superspawn '''to create a child process per-command basis to send the variable and receive a promise. If absolutely must set the environmental variable, delete it as soon as the operations ends.
+  * Throw errors and exceptions when required, not just a notification using console.log.
+  * Avoid heavily ''nested code'', especially with the use of callbacks, where such heavy nesting is common.
+  * Use '''current APIs''', there are plenty of useful node modules implemented under cordova, try to use an existing node module to fit the needs of your code rather than creating redundant code yourself.