Skip to main content

JavaScript coding standards we follow

This document’s primary motivation is twofold:
1) code consistency
2) best practices.
By maintaining consistency in coding styles and conventions, we can ease the burden of legacy code maintenance, and mitigate risk of breakage in the future. By adhering to best practices, we ensure optimized page loading, performance and maintainable code. Therefore, at Innofied, we follow these guidelines strictly while programming.

1 . Proper File Naming Conventions

a) Use Constructor function name as file names. So as per example, file name will be Hero.js
For example:
b) Choose meaningful file names for your JavaScript files like the file names should be derived or chosen by focusing on what the file holds and use CamelCase for your file names.

2 . Indentation

a) The unit of indentation is 4 spaces.
b) Use of tabs should be avoided.
c) Use “format” option of your IDE.

3 . Line Length

a) Avoid line length more than 80 characters.

4 . Proper Comments

a) It is important that comments be kept up-to-date.
b) Make comments meaningful.

5. Variable Declarations

a) All variable should be declared before use.
b) The ‘var’ statement should be the first statement in function body.
c) It is preferred that each variable be given its own line & comment.
For example:
d) Use of global variables should be minimised.
e) Implied global variables should never be used.

6 . Function Declarations

a) All functions used should be declared before use.
b) There should be no space between the name of the function and the ( (left parenthesis of its parameter list. There should be 1 space between the ) (right parenthesis) and the { (left curly brace) that begins the statement body. The right } (right curly brace) is aligned with the line containing the beginning of the declaration of the function.
For example:

7 . Variable Names

a) Names should be formed from the 26 upper and lower case letters(A .. Z, a .. z), the 10
digits (0 .. 9), and _(underbar).
b) Avoid use of international characters.
c) Do not use $(dollar sign) or \(backslash).
d) Do not use _(underbar) as the first character of a name.

8 . Use === Instead of ==

a) JavaScript utilizes two different kinds of equality operators: === | !== and == | != It is considered best practice to always use the former set when comparing.

9 . eval is Evil

a) The eval function is the most misused feature of JavaScript. Avoid it.
b) eval has aliases. Do not use the ‘Function’ constructor. Do not pass strings to ‘setTimeout’ or ‘setInterval’. Instead pass a function name.
For example:
Bad:
Better:

10 . Don’t use short-hand ever

Technically, you can get away with omitting most curly braces and semicolons. Most browsers will correctly interpret the following:
One might think that the code above would be equivalent to:
Unfortunately, he’d be wrong. In reality, it means:
As you’ll notice, the indentation mimics the functionality of the curly brace. Needless to say, this is a terrible practice that should be avoided at all costs.

11 . Utilize JS Lint

JSLint is a debugger written by Douglas Crockford. Simply paste in your script, and it’ll quickly scan for any noticeable issues and errors in your code.

12 . Place scripts at the bottom of your page

The primary goal is to make the page load as quickly as possible for the user.

13 . The fastest way to build your string

Don’t always reach for your handy-dandy “for” statement when you need to loop through an array or object. Be creative and find the quickest solution for the job at hand.
For example:

  • '
  • ) + '';

    14 . Don’t use the ‘with’ statement

    At first glance, “With” statements seem like a smart idea. The basic concept is that they can be used to provide a shorthand for accessing deeply nested objects.
    For example:
    Unfortunately, after some testing, it was found that they “behave very badly when setting new members.” Instead, you should use var.
    For example:

    15 . Use {} intead of new object()

    There are multiple ways to create objects in JavaScript. Perhaps the more traditional method is to use the “new” constructor.
    For example:
    However, this method receives the “bad practice” stamp without actually being so. Instead, it is
    recommend that you use the much more robust object literal method.
    For example:

    16 . Use [] instead of new Array()

    The same applies for creating an array.
    For example:
    Okay:
    Better:

    17 . Long list of variables? Omit the ‘var’ keyword and use commas instead

    For example:
    Okay:
    Better:

    18 . Always use semicolons

    Technically, most browsers will allow you to get away with omitting semi-colons.
    For example:
    Having said that, this is a very bad practice that can potentially lead to much bigger, and harder to find, issues.
    Better:

    19 . Remove ‘language’ Attribute

    Years ago, it wasn’t uncommon to find the “language” attribute within script tags.
    For Example:
    However, this attribute has long since been deprecated; so leave it out.

    Comments

    Popular posts from this blog

    UpComing Features in PHP 5.3

    Namespaces A subject touched and trialed many times in PHP, namespaces. This feature has been responsible for the longest discussions on PHP-DEV, but finally a consensus has arrived on how this is going to work. The biggest benefit namespaces will provide is shortening of long classnames. To make sure that your class libraries can plug into foreign code, it has always been recommended to prefix your classes, for example "Zend_DB_Connection". This can however lead to very long names. Namespaces fixes this by grouping classes together. The full-on classname becomes Zend::DB:Connection, and by placing 'use Zend::DB' on top of your code, the 'Connection' class can be referenced with just that name. Example: // The class file namespace Zend :: DB ; class Connection { function foo () { echo 'bar' ; } } ?> require 'Zend/DB/Connection.php' ; use Zend :: DB :: Connection ; $connection = new Connection (); $connection -> foo (); ?

    Install PHP 5.3.0/Lighttpd On Debian (Lenny) With Imap, MySQL, Sqlite3 And ImageMagick Support

    Install PHP 5.3.0/Lighttpd On Debian (Lenny) With Imap, MySQL, Sqlite3 And ImageMagick Support This tutorial covers the setup of PHP 5.3.0/Lighttpd on Debian (lenny) with imap, mysql, mysqli, sqlite3, ImageMagick and mycrypt support. For this tutorial I will assume you are logged in as root this is not advised. First we need to install the webserver: aptitude install lighttpd Now we install the packages needed for mysql and mysqli support. You will be promoted to enter a mysql root password - please use a strong password. aptitude install mysql-server mysql-client libmysqlclient15-dev Next install some packages php needs to compile. aptitude install libtidy-dev curl libcurl4-openssl-dev libcurl3 libcurl3-gnutls zlib1g zlib1g-dev libxslt1-dev libzip-dev libzip1 libxml2 libsnmp-base libsnmp15 libxml2-dev libsnmp-dev libjpeg62 libjpeg62-dev libpng12-0 libpng12-dev zlib1g zlib1g-dev libfreetype6 libfreetype6-dev libbz2-dev libxpm-dev libmcrypt-dev libmcrypt4 sqlite3 bzip2 build-essential l

    Zend Framework WebServices

    REST Web Services use service-specific XML formats. These ad-hoc standards mean that the manner for accessing a REST web service is different for each service. REST web services typically use URL parameters (GET data) or path information for requesting data and POST data for sending data. Zend Framework provides both Client and Server capabilities, which, when used together allow for a much more "local" interface experience via virtual object property access. The Server component features automatic exposition of functions and classes using a meaningful and simple XML format. When accessing these services using the Client, it is possible to easily retrieve the return data from the remote call. Should you wish to use the client with a non-Zend_Rest_Server based service, it will still provide easier data access. In addition to Zend_Rest_Server and