Differences between revisions 12 and 13
Revision 12 as of 2013-11-07 13:53:41
Size: 1721
Editor: JoshSoref
Comment: Wikify page
Revision 13 as of 2014-04-23 17:22:25
Size: 4198
Comment:
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
The never-ending debate, always a good source for insulting your engineering friends.
Line 3: Line 4:
The never-ending debate, always a good source for insulting your engineering friends.

== General ==

  * 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.
== 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.
Line 10: Line 20:

 
* 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 
  * single quote your string literals; it looks cleaner
  * use literal syntax always {{{ {} [] '' }}}
  * comma first makes it easier to read and catch definition bugs
  * define variables at the top of methods; they'll be hoisted there anyhow
  * 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 - }}}
 * 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.
 * single quote your string literals; it looks cleaner.
 * use literal syntax always {{{ {} [] '' .}}}
 * Use === and !== operators rather than == and != operators.
 *
comma first makes it easier to read and catch definition bugs.
 * 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 -}}}
Line 21: Line 33:
  , "baz":2          , "baz":2
Line 32: Line 44:
Line 34: Line 45:
Line 36: Line 46:

 
* 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
Line 40: Line 49:

 
* 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.
 * 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.
Line 45: Line 53:
== 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.
Line 46: Line 57:
== 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.

Style Guide

The never-ending debate, always a good source for insulting your engineering friends.

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.

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.

  • 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.
  • use literal syntax always  {} [] '' .

  • Use === and !== operators rather than == and != operators.
  • comma first makes it easier to read and catch definition bugs.
  • 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 -

var foo = { "bar":1
          , "baz":2
          }

var arr = [ 1
          , 2
          , 3
          ]

var my = 1
,   little = 2
,   pony = 3

CoffeeScript

  • indent four spaces; note that this does not seem to be defacto standard for CoffeeScript, yet

Java

  • see Eclipse Development Conventions

  • 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.

  • 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.

StyleGuide (last edited 2014-04-23 17:22:25 by MartinGonzalez)