Merge pull request #3897 from NativeScript/etabakov/fix-wrong-example

Fix wrong example of Quotes usage
This commit is contained in:
Alexander Vakrilov
2017-03-30 13:38:45 +03:00
committed by GitHub

View File

@ -55,13 +55,13 @@ Use single quotes, unless you are writing JSON.
*Right:* *Right:*
~~~ {.javascript} ~~~ {.javascript}
var foo = "bar"; var foo = 'bar';
~~~ ~~~
*Wrong:* *Wrong:*
~~~ {.javascript} ~~~ {.javascript}
var foo = 'bar'; var foo = "bar";
~~~ ~~~
## Braces ## Braces
@ -284,6 +284,7 @@ if (a == '') {
[comparisonoperators]: https://developer.mozilla.org/en/JavaScript/Reference/Operators/Comparison_Operators [comparisonoperators]: https://developer.mozilla.org/en/JavaScript/Reference/Operators/Comparison_Operators
## Short-hand oprators ## Short-hand oprators
Try to avoid short-hand operators except in very simple scenarios. Try to avoid short-hand operators except in very simple scenarios.
*Right:* *Right:*
@ -303,6 +304,7 @@ var big = (x > 10) ? checkX(x)?getExtraLarge():getDefaultSize():getSmallValue();
## Curly braces ## Curly braces
Always use curly braces even in the cases of one line conditional operations. Always use curly braces even in the cases of one line conditional operations.
*Right:* *Right:*
@ -325,6 +327,7 @@ if (a) return 'winning';
~~~ ~~~
## Boolean comparisons ## Boolean comparisons
**Do not** directly compare with true, or false. **Do not** directly compare with true, or false.
*Right:* *Right:*
@ -549,6 +552,7 @@ function doAsync(arg, onSuccess, onError) {
~~~ ~~~
## Comments ## Comments
Use the [JSDoc][JSDOC] convention for comments. When writing a comment always think how understandable will be for somebody who is new to this code. Even if it may look simple to you think how a guy that just joined will understand it. Always comment in the following cases: Use the [JSDoc][JSDOC] convention for comments. When writing a comment always think how understandable will be for somebody who is new to this code. Even if it may look simple to you think how a guy that just joined will understand it. Always comment in the following cases:
+ When there is some non-trivial logic. + When there is some non-trivial logic.
+ Some 'external' knowledge is needed which is missing in the context - workaround for driver, module bug, special 'hack' because of a bug and so on; + Some 'external' knowledge is needed which is missing in the context - workaround for driver, module bug, special 'hack' because of a bug and so on;
@ -560,6 +564,7 @@ Use the [JSDoc][JSDOC] convention for comments. When writing a comment always th
## Commenting of parameters that are objects/complex types ## Commenting of parameters that are objects/complex types
When you have parameters that are complex objexts like *options* or other type for which the properties are not clear or is external one use the [@type-def tag][typedef] When you have parameters that are complex objexts like *options* or other type for which the properties are not clear or is external one use the [@type-def tag][typedef]
*Right:* *Right:*
@ -599,6 +604,7 @@ function checkProperties(properties) {
[typedef]: http://usejsdoc.org/tags-typedef.html [typedef]: http://usejsdoc.org/tags-typedef.html
## File/module structure ## File/module structure
Typical module should have the following structure: Typical module should have the following structure:
1. required dependencies 1. required dependencies