javascript coding standards 2014


JavaScript Coding Standards
SCOPE:
OBJECTIVES:
JAVASCRIPT:
NAMING CONVENTIONS
NAMING VARIABLES
NAMING M ETHODS
NAMING PARAMETERS
SYNTAX CONVENTIONS

Code Formatting: Use white spaces and indents to make the code readable.

Semicolons: Use a semicolon at the end of each statement.
FILE ORGANIZATION
BLOCK COMMENTS
SINGLE-LINE COMMENTS
TRAILING COMMENTS
END-OF-LINE COMMENTS
MISCELLANEOUS PRACTICES:
PARENTHESES
PERFORMANCE ISSUES :
NETSCAPE ISSUES
SCOPE:
This documents the coding standards for JavaScript. Java Script is used in Web
pages to add interactivity and conditional logic.
OBJECTIVES :
The objectives of the conventions are to make code:
• More readable: Conventions allow a reader to understand the meaning of the
code with less effort.
• More maintainable: The code can be more reliably changed to fix bugs and
enhance functionality.
• More reliable: The code is more likely to perform as expected.
• More efficient: The code performs faster or consumes fewer resources.
JAVASCRIPT:
Unlike HTML, which is not case sensitive, JavaScript is a case sensitive
language. In order to decrease the potential for bugs and to increase readability of
the code, it is important to maintain consistency in capitalization. Capitalization
guidelines need to apply to JavaScript keywords, classes, functions, variables and
any other identifiers.
1. Begin names with a character (lower or uppercase as defined below) or
underscore, nothing else. Subsequent characters may be any letter, digit or an
underscore.
2. Use names that are descriptive
3. Do not place any spaces in the name
NAMING CONVENTIONS
Nam ing Variables
For consistency in naming variables, use initial capital letters in variable
names (do not capitalize prefixes). If the identifier has a type, indicate it
(again, prefixes or suffixes are useful here). JavaScript is weak on type
checking which can lead to errors which are only detected at run-time.
Clearly distinguishing a variable of one type from another can reduce the
defects that are missed.
To make the intended use of a variable clear to others reading your code,
use three-character prefixes to indicate data type.
Data Type
♣ Byte
♣ Char
♣ Integer
♣ Double
♣ Float
♣ Long
♣ Object
♣ String
♣ Boolean
Prefix
byt
chr
int
dbl
flt
lng
obj
str
bln
For Eg:
Var strFirstName;
Naming Methods
Methods should be verbs, in mixed case with the first letter lowercase,
with the first letter of each internal word capitalized.
Examples:
get ()
getData ()
formValidate()
checkNumeric()
All common methods should be saved as .js file
Naming Parameters
Function parameters are named the same as simple variables of the same
type.
Guideline Example Rationale
File names: Use only File name: browsercheck Standardization for
lowercase. consistency in maintaining
          correct filenames in case
         sensitive environments.
File structure: Place Filename: date.js Readability of base HTML
JavaScript in separate code. Hide JavaScript from
".js" files. Reference them users.
from the HTML file used 
in. 
Class names: Name Class name: Industry best/standard
classes with an initial CircleManipulation practice.
capital letter. Capitalize 
each word thereafter. 
Class objects: Name the Class instance name: Industry best/standard
instances (objects) of circleManipulationInstanc practice.
classes with lower case e 
letters. Capitalize each 
word thereafter. 
Variables: Start a variable Variable name: Maintain consistency in
with a lowercase letter myNumberVariable case sensitive
and capitalize the first environments to reduce
letter of each word errors.
thereafter. 
Syntax Conventions
The syntax of a program is the set of rules that must be adhered to in
writing the code so that it can be interpreted or compiled properly. The
following table depicts guidelines where the syntax may be written in
more than one way.
q
Code Formatting: Use white spaces and indents to make the code
readable.
Example:
for(i=0;
{
i < 10;
i++)
statement1 ...
statement2 ...
}
q
Semicolons: Use a semicolon at the end of each statement.
JavaScript does not require a semicolon at the end of a statement if
it is on its own line. Semicolons should always be used for
readability, consistence, and ease in debugging.
Example:
a=3; NOT a=3
b=2; b=3
FILE ORGANIZATION
A file consists of sections that should be separated by blank lines and an optional
comment identifying each section.
Files longer than 2000 lines are cumbersome and should be avoided.
Proper commenting should be done for each function
All Separate JS file should begin with a proper commenting regarding the
functionality of the JS file.
/* File Name :
* Description/Purpose:
* Date :
* Revision Date :
*/
All functions should begin with proper comment that lists the summary , input
and output information, date, and author’s name:
/*
*
*
*
*
*
*
*
*
Function name :
Description
Inputs and Ouputs:
Date:
* Author:
*/
Proper inline commenting should be done for each function.
Comments should not be enclosed in large boxes drawn with asterisks or other
characters.
Comments should never include special characters such as form-feed and
backspace.
Block Comments
A block comment should be preceded by a blank line to set it apart from
the rest of the code.
/*
* Here is a block comment.
*/
Single-Line Comments
Short comments can appear on a single line indented to the level of the
code that follows. If a comment can't be written in a single line, it should
follow the block comment format A blank line should precede a single-
line comment. Here's an example of a single-line comment in Javascript
code
if (condition) {
/* Handle the condition. */
...
}
Trailing Comments
Very short comments can appear on the same line as the code they
describe, but should be shifted far enough to separate them from the
statements. If more than one short comment appears in a chunk of
code, they should all be indented to the same tab setting.
Here's an example of a trailing comment in Javascript code:
if (a == 2) {
return true;
} else {
return isPrime(a);
*/
}
/* special case */
/* works only for odd a
End-Of-Line Comments
The // comment delimiter can comment out a complete line or only a
partial line. It shouldn't be used on consecutive multiple lines for text
comments; however, it can be used in consecutive multiple lines for
commenting out sections of code. Examples of all three styles follow:
if (foo > 1) {
// Do a double-flip.
...
}
else {
return false;
}
// Explain why here.
//if (bar > 1) {
//
//
// Do a triple-flip.
//
...
//}
//else {
//
return false;
//}
One declaration per line is recommended since it encourages commenting. In
other words,
var level; // indentation level
var size; // size of table
is preferred over
var level, size;
Note: The examples above use one space between the type and the identifier.
Another acceptable alternative is to use tabs, e.g.:
MISCELLANEOUS PRACTICES:
Parentheses
It is generally a good idea to use parentheses liberally in expressions
involving mixed operators to avoid operator precedence problems. Even if
the operator precedence seems clear to you, it might not be to others-you
shouldn't assume that other programmers know precedence as well as you
do.
if (a == b && c == d)
// AVOID!
if ((a == b) && (c == d)) // RIGHT
§ The Form elements are to be always accessed with
  Document.formname.objectname
 (Document is mandatory)
Example:- window.opener.document.formname.objectname
§ The Script tag should always be specified as
<Script Language = ”Javascript”> </Script>
and not as
<SCRIPT></SCRIPT>
§
Always write the javascript code (either script itself or include js file
)on top of the page..so that it is loaded completely when the page is
displayed. Otherwise there are chances to get run time error : “Object
not found..”
PERFORMANCE ISSUES :
Declaration of variables globally and reusing them instead of declaring fresh ones
for small purposes
Being very specific about Array size when it is declared dynamically .ie unused
array locations wud waste resources
While checking browser compatibility with the aim of code reliability across
browsers, it is advisable to check for Object compatibility alongwith/rather than
browser check .This would lessen the rework on code when new versions of
browsers release and the features they have varies .
if (name of object you're detecting here) {
operations upon that object here
}
else
{
the remaining alternative
)
rather than
if (a specific browser)
{
this way
}
else
{
this way
}
The second way would become tedious when we have more browsers to check for
compatibility and also each one’s version difference to tackle as well. This aspect
is most helpful when combining DHTML and Javascript
NETSCAPE ISSUES
 All HTML tags should be checked for appropriate opening and closing
  (should be in pairs correctly)
 If you want to generate a table dynamically using an ASP loop, actually we
  want only the rows showing the details of the table to be incremented.
So put only the <TR><TD>Details</TD></TR> Inside the loop.
Example:
1.
<TABLE>
<TR><TD>Heading</TD></TR>
FOR I=1 to 5
<TR><TD>Details</TD></TR>
NEXT
</TABLE>
2.
<TABLE>
<TR><TD>Heading</TD></TR>
FOR I=1 to 5
<TR><TD>Details</TD></TR>
</TABLE>
NEXT
The second example is wrong. When it comes in IE, It will not create
problem. But in netscape that page won’t be displayed as desired..
 Every form should contain only a single submit button.
  i.e only a single <input type=”image” src=”a.asp”> to be present in a
         form. (Netscape and IE will take the Input type=”Image” as submit button)
 Check for spaces in strings before submitting to Action Pages.
  The spaces are to be replaced appropriately with %20 before submitting. In
 case of javascript functions the escape() function can be used for this and in
Response.redirect the server.urlencode is to be used.
 The java script functionalities need to be checked for Netscape compatibility.
 No cells (<TD> of tables) are to be left empty. The empty cells are to be
  written with &nbsp;
 In javascript functions etc, the form elements are to be always accessed with
  Document.formname.objectname
 (Document is mandatory)
 The form elements cannot be disabled by “Disabled” use “onFocus =
        this.blur()” instead. In some cases we have to check the browser and give
         ‘disabled’ when its IE and ‘Blur’ if Netscape (in case of comboboxes)
 The script tag should always be specified as
<Script Language = ”Javascript”>
and not as <SCRIPT></SCRIPT>
 To Do: When centering objects on an HTML page use
  <center> OBJECT </center>
 Not To Do: The <p align=center> OBJECT </p> that IE uses does not
work in Netscape
 Image names cannot have spaces, otherwise the image disappears in
  Netscape!
 If you use a name in the image tag like this <img src="my image.gif">
  Netscape does not display it, you must connect the string to either <img
 src="my_image.gif"> or be sure to reference the filename in HTML like:
<img src="my%20image.gif">
 Any form element that is created in Netscape must be included within a form,
  or else Netscape does not even show the button.
 In addition to including all elements within form tags you must also reference
  the form elements by calling them out explicitly such as
 document.buttonpanel.mybutton, not just mybutton, otherwise you cannot
access these elements in Netscape.
 When using the select() function to access a value within an element, like
  text within a field, first use focus() then select() to allow Netscape to work
 properly.
 Do not try to highlight text like this in Netscape
document.formname.textbox.select()
Use this instead:
document.formname.textbox.focus()
document.formname.textbox.select()

The window.open options string must contain no spaces, otherwise the
function will fail to fire properly with the correct options in Netscape.
 All tables must have proper closing tags such as </td>, </tr>, </table>
  or else the entire table disappears in Netscape. Netscape is ruthless in this
 respect, if you have a table with multiple inner tables trying to find that one
missing tag can be a tough job. Best way to solve this problem is to indent and
indent with accuracy.
 To Do: Use document.formname.radioname[i].checked for radio buttons.
  Do not use: document.formname.radioname.item[i].checked, otherwise
 the value will be returned as undefined in Netscape.
 To remove the bottom scroll bar of a textarea in Netscape is WRAP=PHYSICAL
  or Wrap=hard.

Advertisements
About

myself pramodh kumar yet another php developer from India and have worked on oops,procedural,yii framework,codeigniter,wordpress,joomla,api and more.

Tagged with: , , , , ,
Posted in javascript

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow php tutorial on WordPress.com
categories
Calendar
March 2014
M T W T F S S
« Feb   Apr »
 12
3456789
10111213141516
17181920212223
24252627282930
31  
Follow me on Twitter
Blog Stats
  • 74,607 hits
%d bloggers like this: