List Of Rules
- Here I'm putting some rules we all have to follow when writing javascript applications.
- They can be applied not only for Sophie, I've read some books and compiled the rules (mainly from the JavaScript The Good Parts)
- There are some simple rules for writing HTML too.
Google's JavaScript rules
- We will follow the Google's rules for writing JavaScript...
- Link to the rules.
- Many of the bellow listed thing are similar.
HTML rules
- The style attribute of HTML tags should not be used, if possible.
- Presentational HTML tags such as <font> should not be used at all.
- Tags should be used for their semantic meaning, not because of how browsers render them by default.
For instance, developers sometimes use a <div> tag where a <p> would be more appropriate. It's also favorable to use <strong> and <em> instead of <b> and <i> as the latter describe the visual presentation rather than the meaning.
- Minimize the number of <script> tags.
- Avoid inline event handlers. (like <div onclick='function (e) {code, code, code, code}'>)
- Dynamically add markup that has no purpose when JavaScript is disabled by the user.
- See the CSS rules : CssRules .
JavaScript rules
Avoid global variables
- WHAT : The worst of all of JavaScript’s bad features is its dependence on global variables.
A global variable is a variable that is visible in every scope.
- WHY : Global variables make it harder to run independent subprograms in the same program.
If the subprograms happen to have global variables that share the same names, then they will interfere with each other and likely fail, usually in difficult to diagnose ways.
- AWFUL : You can use a variable without declaring it. This is called implied global - foo = value; .
This was intended as a convenience to beginners by making it unnecessary to declare variables before using them. Unfortunately, forgetting to declare a variable is a very common mistake. JavaScript’s policy of making forgotten variables global creates bugs that can be very difficult to find.
Avoid semicolon insertion (not putting explicitly semicolons)
- WHAT : JavaScript has a mechanism that tries to correct faulty programs by automatically inserting semicolons.
Do not depend on this. It can mask more serious errors. Put semicolons at the end of every expression.
- WHY : It sometimes inserts semicolons in places where they are not welcome.
Consider the consequences of semicolon insertion on the return statement. If a return statement returns a value, that value expression must begin on the same line as the return:
return
{
status: true
};
This appears to return an object containing a status member. Unfortunately, semi-colon insertion turns it into a statement that returns undefined. There is no warning that semicolon insertion caused the misinterpretation of the program. The problem can be avoided if the '{' is placed at the end of the previous line and not at the begin-ning of the next line:
return {
status: true
};
- IMPORTANT : The curly brackets should be put on the line the 'if', 'else', 'function', etc is defined.
That convention is better ofr every programming language, even C++. So we will use it.
Avoid using '==' and '!='
- WHAT : JavaScript has two sets of equality operators: === and !==, and their evil twins == and !=.
The good ones work the way you would expect. If the two operands are of the same type and have the same value, then === produces true and !== produces false. The evil twins do the right thing when the operands are of the same type, but if they are of different types, they attempt to coerce the values. The rules by which they do that are complicated and unmemorable.
- WHY :
'' == '0' // false 0 == '' // true 0 == '0' // true false == 'false' // false false == '0' // true false == undefined // false false == null // false null == undefined // true ' \t\r\n ' == 0 // true
Avoid using 'eval'
- WHAT : The eval function passes a string to the JavaScript compiler and executes the result.
It is the single most misused feature of JavaScript. It is most commonly used by people who have an incomplete understanding of the language.
- WHY : The eval form is much harder to read.
This form will be significantly slower because it needs to run the compiler just to execute a trivial assignment statement. The eval function also compromises the security of your application because it grants too much authority to the eval’d text. And it compromises the performance of the language as a whole in the same way that the with statement does.
- IMPORTANT : Do not use the Function constructor ofr creating functions (it acts like the eval).
Be carefull using setInterval and setTime.
Avoid block-less statements
- WHAT : An if or while or do or for statement can take a block or a single statement.
- WHY : The single statement form is another attractive nuisance.
It offers the advantage of saving two characters, a dubious advantage. It obscures the program’s structure so that sub-sequent manipulators of the code can easily insert bugs.
if (ok)
t = true;
can become:
if (ok)
t = true;
advance( );
which looks like:
if (ok) {
t = true;
advance( );
}
but which actually means:
if (ok) {
t = true;
}
advance( );
Programs that appear to do one thing but actually do another are much harder to get right. A disciplined and consistent use of blocks makes it easier to get it right.
- IMPORTANT : This thing is important for every programming language...
Some 'knowledge' which comes from the university is actually harmfull.
Avoid bitwise operators
- WHAT : JavaScript has the same set of bitwise operators as Java: & | ^ ~ >> >>> <<
- WHY : In Java, the bitwise operators work with integers.
JavaScript doesn’t have integers. It only has double precision floating-point numbers. So, the bitwise operators convert their number operands into integers, do their business, and then convert them back. In most languages, these operators are very close to the hardware and very fast. In JavaScript, they are very far from the hardware and very slow. JavaScript is rarely used for doing bit manipulation. As a result, in JavaScript programs, it is more likely that & is a mistyped && operator. The presence of the bitwise operators reduces some of the language’s redundancy, aking it easier for bugs to hide.
Avoid typed wrappers
- WHAT : JavaScript has a set of typed wrappers. For example: new Boolean(false) produces an object that has a valueOf method that returns the wrapped value.
- WHY : This turns out to be completely unnecessary and occasionally confusing.
Don’t use new Boolean or new Number or new String. Also avoid new Object and new Array. Use {} and [] instead.
List of values that return 'false'
- 0 - the type is Number
- NaN - the type is again Number(!)
- - the empty string
- false - the Boolean false
- null - the type is Object(!)
- undefined - the type is special - undefined
