Programming Standards for NetSuite

Revision History

Version Date Notes

1.0 21 October 2011 Initial Version
1.1 21 February 2012 Revisions for error handling
1.2 12 March 2012 Published
1.3 14 November 2012 Addition of Appendices, Installing SuiteCloud IDE, Installing
Subversion and General Structure
1.4 15 November 2012 Addition made to the Naming Standard
1.5 20 May 2013 Addition of file Naming Standard and Script Template
1.6 17 December 2013 Removed watermark & moved figures.
1.7 25 February 2014 Addition of constant variable convention & changes to SVN install

1.8 12 March 2014 corrected name for naming conventions

1.9 21 March 2014 Addition of FHLParseFloat & FHLParseInt

Page 1
Table of Contents
Table of Contents....................................................................................................................................... 2

1. Overview................................................................................................................................................ 3

2.0 General Structure................................................................................................................................. 3

2.1. File Organisation............................................................................................................................ 3

Figure 1........................................................................................................................................ 4

2.2. Version Numbers............................................................................................................................ 4

2.3. Naming Standard............................................................................................................................ 4

Figure 2........................................................................................................................................ 4

Figure 3........................................................................................................................................ 5

Figure 4........................................................................................................................................ 5

2.4. Indentation, Bracing and Whitespace............................................................................................. 5

Figure 5........................................................................................................................................ 6

Figure 6........................................................................................................................................ 7

2.5. Comments...................................................................................................................................... 7

Figure 7........................................................................................................................................ 7

2.6. Declarations.................................................................................................................................... 7

Figure 8........................................................................................................................................ 7

2.7. Error Handling................................................................................................................................ 8

Figure 9........................................................................................................................................ 8

2.8. NetSuite Specific Considerations................................................................................................... 8

2.9. General Principles.......................................................................................................................... 9

2.10 Script Template........................................................................................................................... 10

Figure 10................................................................................................................................... 10

3.0 Installing SuiteCloud IDE.................................................................................................................... 11

3.1 To install SuiteCloud on your machine..........................................................................................11

3.2 Setting up SuiteCloud IDE............................................................................................................. 11

3.3 Set your password......................................................................................................................... 11

4.0 Installing Subversion (SVN) on SuiteCloud........................................................................................ 12

4.1 Installing SVN................................................................................................................................ 12

Figure 11.................................................................................................................................... 12

5.0 Programming Standards Update........................................................................................................ 13

Page 2
1. Overview
The standards are intended to improve the quality, readability and maintainability of the source
code.

This standard will be supported by a peer-review process prior to full customer release. This
process will ensure that the standards are being adhered to and that the code is understandable
and maintainable on an on-going basis.

2.0 General Structure

2.1. File Organisation

• A file should contain only one type of script, i.e. server side scripts should be in
separate files to client side scripts.

• All files should contain a header block as shown below.

/********************************************************************
* Name: The name of the script – script.js
* Script Type: Type of deployment, e.g. Client, Suitelet
*
* Version: 1.0.1 – 12/12/2012 – 1st release - JM
* 1.0.2 – 24/12/2012 – bug 121 resolved - AC
* 1.0.3 – 03/05/2013 – added expense calculation - PA
* 1.0.4 – 12/12/2014 – resolved bug 900 – JM
*
* Author: FHL
*
* Purpose: A description of the purpose of this script,
* together with its method of deployment.
*
* Script: The script record id – custscript_script
* Deploy: The script deployment record id – customdeploy_script
*
* Notes: If the script is linked to a form and other Dependencies
*
* Library: library.js
*******************************************************************

• The version history should reflect the general changes made, when they were made and
who made the changes. If several changes are being made at the same time – use
version number 1.

• Typically, to allow traceability of changes, the version number should be used to

highlight in function header remarks the specific change made to modified functions
or newly added functions. The function header should also contain a reference to any
parameters and return variables. (Figure 1)

Page 3
Figure 1

/**
*
* Page Initialise
*
* @param startDate (start date of contract)
* @param endDate (end date of contract)
* @returns {date}
*
* 1.0.4 resolved bug 900
*
*/

2.2. Version Numbers

• All files should be versioned using the format x.y.z, where x is the major release and
y the minor release. Z represents the build and should be incremented on every
release cycle.

• Minor releases should be incremented when functions are added or removed.

• Major releases should be incremented when there is a significant change in the

code and function structure.

2.3. Naming Standard

• Language elements should be named in such a way as they provide a meaningful
insight into their function or purpose. The use of ‘my’ and ‘the’ should be avoided.

• The naming of Files, Folders, Saved Searches, Custom Forms and the like should
reflect its purpose. (Figure 2)

Figure 2
To create a name for a Saved search for ‘Customers called Dave’

Correct Customers Called Dave

Incorrect My search

Dave

SEARCH DAVE

• Custom Id’s should start with an underscore and be written in lowercase. (Figure 3)

Page 4
Figure 3
To create an id for a Saved Search called ‘Customers called Dave’

Correct _customerscalleddave

Incorrect _customers_caled_dave

_Customers_Called_Dave

_CUSTOMERS_CALLED_DAVE

_CUSTOMERSCALLEDDAVE

_CustomersCalledDave

• Variables should be capitalised using the ‘camelBack’ capitalisation technique. The

first letter of an identifier should be lowercase and the first letter of each
subsequent concatenated word is capitalised.(Figure 4)

• To make constants stand out they should use the 'SCREAMING_SNAKE_CASE'

Technique(Figure 4)

Figure 4

Variable Constant

Correct var exchangeRate Var EXCHANGE_RATE

Incorrect var ExchangeRate var exchange_rate

var exchangerate var exchangerate

var exchange_rate var exchangeRate

Var EXCHANGE_RATE

• Do not use underscores in variable names unless it is a constant.

• Do not create two elements that differ only by case and avoid using the same
name for variables and functions.

• Script & deployment id's should use the scripts name after the _.

“custscript_transformSO”
“customdeploy_transformSO”

2.4. Indentation, Bracing and Whitespace

• Indentation should be used to enhance readability. Indentation should be in units
of 4 characters. (Figure 5)

Page 5
Figure 5
Correct if (i == exchangeRate)
{
foreignAmount = 1;
}

switch (exchangeRate)
{
case 1:
foreignAmount = 2;
break;
case 2:
foreignAmount = 6;
break;
}

Incorrect If (i == exchangeRate) foreignAmount = 1;

switch (exchangeRate)
{
case 1:
foreignAmount = 2;
break;
case 2:
foreignAmount = 6;
break;
}

• For compound statements (if, for loops, switch blocks), open braces should be on
the line following the statement that begins a block.

• ‘If’ statements should always be written as compound statements, with braces

surrounding the dependant statements. One line ‘if’ statements should not be used.

• To aid readability try to keep code from straying outside the visible windowls.

• Whitespace should be used to increase the readability of code. For example,

(i<0) should be expressed as (i < 0).

• Spacing between parameters within parentheses should be applied after the

comma. (Figure 6)

Page 6
Figure 6

Correct function hello(cat, count, dog)

{
//code
}

Incorrect function hello(cat,count,dog)

{
//code
}

2.5. Comments
• Comments should be used to enhance the reader’s understanding of the code with
respect to its intention, algorithmic overview, and/or logical flow.

• The double slash (‘//’) style of comment tags are preferred over the /* */ syntax, with
the exception of file and function headers.

• Comments are to be added to help indicate structure of function. (Figure 7)

Figure 7
Function()
{
//Declarations
//Process
//Return
}

2.6. Declarations
• All variables should be declared using the ‘var’ keyword prior to use, to minimise
overheads in traversing the scope.

• All variables should be initialised to a default value or explicitly set to ‘null’.

• It is preferred to declare variables together at the top of a function.

• Variables should be declared and initialised on a single line. (Figure 8)

Figure 8

Correct var count = 0;

var cat = null;

var count = cat;

Incorrect var count = 0, cat = null;

Page 7
 2.7. Error Handling
• All functions should handle errors by using the ‘try…catch’ statement.
• During an error condition the error should be written to the NetSuite script
deployment using nlapiLogExecution. (Figure 9)
• All debug log executions should be removed prior to release.

Figure 9

try
{
// Run some code here
}
catch(e)
{
//Handle errors here
errorHandler(‘error message’, e);
}

• Setting Log Level:

• ERROR – Should be set when the script is released.

• DEBUG – Should be set when the script is being tested and should be removed
when testing has been passed and finished.
• AUDIT – Is to be used when a financial calculation is expected.
• EMERGENCY – Should only be used when failure would have a critical
consequence.

2.8. NetSuite Specific Considerations

• For client scripts, the execution of nlapiSetFieldValue and
nlapiSetCurrentLineItemValue is multi-threaded whenever child field values need to
be sourced in. Use the postSourcing function to synchronize your logic. Setting the
synchronous parameter to true in both nlapiSetFieldValue and
nlapiSetCurrentLineItem will accomplish the same thing.

• For speed and governance use nlapiLookupField instead of nlapiLoadRecord for

fetching body field values. Note that you can fetch multiple fields at the same time.

• For speed and governance use nlapiSubmitField instead of nlapiSubmitRecord for

updating body field values. Note that you can submit multiple fields at the same time.

Page 8
2.9. General Principles
There are a number of general principles that developers should adhere to in order
to promote code re-use, code readability and to promote code that is easy to service:

• Each function should perform one task.

• Functions should typically be no more than a few pages long.

• If a function is too long it should be refactored into a series of calls.

• Each line of code should be one statement – avoid performing multiple instructions
per line of code.

• Code should be structured in such a way as to ensure there is only one exit point.

• If a line of code spans more than the readable width of the screen, split it.

• Always use a string to populate a date field and not the NetSuite date conversion
function. E.g. - nlapiDateToString( date, dateFormat)

• Numeric values retrieved from NetSuite must be immediately parsed before any
calculations using FHLParseFloat(value) or FHLParseInt(value)

Page 9
 2.10 Script Template
This is an example template that should be used at the start of any script file.
(Figure 10)

Figure 10

/*************************************************************************************
* Name: [todo]
* Script Type: [todo]
*
* Version: [todo]
*
* Author: [todo]
*
* Purpose: [todo]
*
* Script: [todo]
* Deploy: [todo]
*
* Notes: [todo - deployment details i.e. form associated etc]
*
* Library: [todo]
*************************************************************************************/

var sample = '';

/**
* scriptTemplate
*/
function scriptTemplate()
{
initialise();
process();
}

/**
* initialise
*/
function initialise()
{
try
{

}
catch(e)
{
errorHandler("initialise", e);
}
}

/**
* main process
*/
function process()
{
try
{

}
catch(e)
{
errorHandler("process", e);
}
}

Page 10
3.0 Installing SuiteCloud IDE

3.1 To install SuiteCloud on your machine

• Log into NetSuite.
• Select the ‘Help’ link at the top right of the screen.
• Type ‘SuiteCloud’ into the search bar at the top right of the screen.
• Select the link ‘Installing SuiteCloud IDE’.
• Install the SuiteCloud IDE that is specific to your operating system.

3.2 Setting up SuiteCloud IDE

• Open the SuiteCloud folder.
• Select the eclipse.exe file.
• The Workspace Launcher will ask you where to store your Workspace.
• Click ‘ok’ once you’ve selected the destination.

3.3 Set your password

• Select ‘NetSuite > Master Password > Revoke Password’ from the menu at the top.
• Then create a master password.

Page 11
4.0 Installing Subversion (SVN) on SuiteCloud

4.1 Installing SVN

• Select ‘Help > Install New Software’ from the menu at the top.
• In the ‘Work with:’ text box type – http://subclipse.tigris.org/update_1.8.x
• Click add
 Check both Subclipse and SVN Kit check boxes.
• Click next and make sure all are selected.
• Click finish.

4.2 Accessing SVN Repositories in SuiteCloud

• Select ‘Window > Show View > Other’.
• Select ‘SVN > SVN Repositories’.
• This will bring up a new fast view tab called SVN Repositories. Select the SVN
image. (Figure 11)

Figure 11

• Add the URL https://svn.firsthosted.co.uk:8443/svn/Test into the Location field.

• Click finish
• Then add in your username and password in the format below.

Username: dwhite – first initial & surname

Password: dw9876#! - initials & '9876#!'

Page 12
5.0 Programming Standards Update

1. All code must conform to the standards as it as being written, rather than amending it to fit the
standards when it is complete and submitted to the repository.

2. Developers should not introduce personal standards when writing code, especially when naming
conventions are introduced.

3. camelBack should be applied to all naming conventions excluding script and deployment names
& constant variables. Please note this refers to using lower camelBack.

Correct lowerCamelBack

Incorrect LowerCamelBack
lowercamelcase

4. Only use underscores to separate the NetSuite prefix to the script/deployment name. It should
not be used anywhere else.

Correct customscript_salesorderxml

Incorret customscript_tibco_salesorder_xml

5. Do not prefix the script/deployment name with the script type as it should be named solely after
the purpose.

Correct customdeploy_listpriceengine

Incorrect customdeploy_usereventlistpriceengine

6. The script name and deployment ID should always be the same, however this does not apply to
scripts that have multiple deployments. In cases of multiple deployments, take the context of its
purpose into account whilst naming.

Correct customdeploy_vatengineevents
customdeploy_vatenginetibco
customdeploy_vatenginesalesorder

Incorrect customdeploy_vatengine1
customdeploy_vatengine2
customdeploy_vatengine3

Page 13
7. Variables and any custom elements within NetSuite such as: custom record sets, entity fields
and transaction column/body fields should not contain a prefix.

Correct Variable: vatEnabled

Record Set: Contract Item

Incorrect Variable: FHLVatEnabled

Record Set: FHL Contract Item

8. If numerous amendments are being made to a piece of code during a short space of time,
ensure that the same version number is used. Follow this rule on a case by case basis.

Correct 1.0.1 – 18/11/13 JM

1.0.1 – 19/11/13 JM

_______________________

1.0.1 – 18/11/13 JM
1.0.2 – 18/11/15 JM

Incorrect 1.0.1 – 18/11/13 JM

1.0.2 – 19/11/13 JM

9. Ensure to add header and function blocks containing the version number and the changes made
to the script if you are amending code that has been written pre standards or by a third party.

10. When making amendments to an old script, ensure you avoid overcomplicating it by minimising
the changes you include within the pre-existing code. Introduce a function to handle the
modifications outside.

Correct code
call function
code

function

Incorrect Code
↑
function
↓
code

Page 14