[go: up one dir, main page]

0% found this document useful (0 votes)
15 views7 pages

Convention and Standards

The document outlines JavaScript coding standards and conventions for the University of Southern Mississippi, emphasizing the importance of standardization for effective product delivery. It details naming conventions, coding practices, and style guidelines to ensure code readability and maintainability. Additionally, it provides templates for creating classes within their framework and states that the document is subject to updates by lead developers.

Uploaded by

new.baks
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
15 views7 pages

Convention and Standards

The document outlines JavaScript coding standards and conventions for the University of Southern Mississippi, emphasizing the importance of standardization for effective product delivery. It details naming conventions, coding practices, and style guidelines to ensure code readability and maintainability. Additionally, it provides templates for creating classes within their framework and states that the document is subject to updates by lead developers.

Uploaded by

new.baks
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 7

University of Southern Mississippi

JavaScript Code Standards


Conventions and Standards

Isaiah D. Williams, School of Computing, University of Southern Mississippi


5/31/2010
Contents
1. Preface .................................................................................................................................................. 2
2. Naming Conventions and Style ............................................................................................................. 3
2.1. Naming Conventions ..................................................................................................................... 3
2.1.1. Variables................................................................................................................................ 3
2.1.2. Functions/Methods ............................................................................................................... 3
2.2. Style............................................................................................................................................... 3
3. Coding Practices .................................................................................................................................... 5
1. Preface
A comprehensive coding standard is essential for a successful product delivery. Standardization helps
enforce best practices and avoiding pitfalls, and makes knowledge dissemination across the team easier.
Traditionally, coding standards are thick, laborious documents, spanning hundreds of pages and
detailing the rationale behind every directive. While these are still better than no standard at all, such
efforts are usually indigestible by the average programmer. In contrast the JavaScript coding standards
presented in this document are “thin on the why” and are “detailed on what and how”. Understanding
every insight that goes into a particular programming decision may require lots of background reading
and years of experience, applying programming standards should not. When absorbing a new
programmer into a team, they should be able to simply read the standards and by doing so they will
have a basic understanding of how write code that will be effective and function well in the given shop.
Being able to comply with a good standard will come before fully appreciating and understanding it-that
will come over time and with experience. The coding standard presented within this document captures
best practices, pitfalls, guidelines, and recommendations, as well as naming conventions and styles, and
structure.
2. Naming Conventions and Style

2.1.Naming Conventions
In computer programming, a naming convention is a set of rules for choosing the character
sequence to be used for identifiers which denote variables, types and functions etc. in source
code and documentation. If the first letter is capitalized, it is called Pascal case; if not, then
camel case.

2.1.1. Variables
a. Use camel casing for local variable names and method arguments i.e.

function MyMethod(elapsedTime) {

var time;
};

b. Use descriptive variable names


a. Avoid single character variable names, such as i, use index or temp instead
b. Do not abbreviate words (such as num instead of number)
c. All member variables should be declared at the top, with one line separating them
from the rest of the method

2.1.2. Functions/Methods
a. Use Pascal casing for type and method names i.e.

function MoveTool() {
MoveTools.prototype.SelectTool = function() { }
};
b. Name method using verb-object pair, such ShowDialog

2.2.Style
Programming style is a set of rules or guidelines used when writing the source code for a
computer program. It is often claimed that following a particular programming style will help
programmers to read and understand source code conforming to the style, and help to avoid
introducing errors.

a. All comments should pass spell checking


b. Always place the an open curly brace on the same line of the declaration,
conditional statement, or loop where it is needed
c. Group all framework namespaces together and put custom or third-party
namespaces underneath
d. Indent comments at the same level of indentation as the code being documented
e. Maintain strict indentation; do not use nonstandard indention, such as one space,
recommended values are four spaces or tab, and the value should be uniform across
f. Terminate all functions with a semicolon i.e.

function MyMethod() {

};
3. Coding Practices
a. Always copy the current working version to a scratch space to do any development; no one
should alert the working version other than the integration team
b. Avoid putting multiple classes in one file
c. Avoid methods with more than 200 lines
d. Lines should not exceed 80 characters
e. Avoid comments that explain the obvious. Code should be self-explanatory. Good code with
readable variable and method names should not require comments
f. Document only operational assumptions, algorithm insights and so on
g. If declaring a class always declare a class variable that is equal to ‘this’ to be used to reference
variables and perform method calls
h. With the exception of zero and one, never hard-code a numeric value; always declare a constant
instead
i. Every line of code should be walked through in a “white-box” testing manner
j. Catch only exceptions for which you have explicit handling
k. Always use a curly brace scope in an if statement, even if it conditions a single statement
l. Never hardcode strings that will be presented to end users, use resources instead
m. Never hardcode strings that might change based on deployment such as connection strings

Just like everything in JavaScript classes can be built several different ways. With the development
of this project our developers have create a framework and a template for all classes. If you need to
create a class that needs to be initialized then use the following template

bimjs.provide('bimjs.TEMPLATE');
bimjs.require('bimjs.scene');

/**
* A module for TEMPLATE.
* @namespace
*/
bimjs.TEMPLATE = function () {
var self = this;
this.classLevelVariable = 0;

bimjs.TEMPLATE.prototype.FunctionName() { };
};

Note that bimjs.provide tells the framework that this class provides the following framework and
that bimjs.require indicates that this class is dependent on another one (like the avatar class is
dependent upon the scene class).
Now if you need to create a static class use the following template

bimjs.provide('bimjs.TEMPLATE');

/**
* A Module for a template static class.
* @namespace
*/

bimjs.TEMPLATE = bimjs.TEMPLATE || {};

bimjs.TEMPLATE.MyFunction = function () {};

In closing this document is subject to change under the direction of the lead developers. When
changes are made to this document is the responsibility of the individual who makes the change to
inform the development team

You might also like