|
General
|
-
Don't write your SuiteScript code in a clever manner. Write it in a straightforward, obvious way.
-
Follow the Do Not Repeat Yourself (DNRY) principle. Consider creating reusable functions.
|
|
Using SuiteScript modules
|
-
When you specify the modules that your script uses, make sure that the order of the modules matches the order of the parameters in your main function. For example, if your script uses the N/error, N/record, and N/file modules and you specify them in this order, make sure that your function parameters are in the same order, as follows:
require(['N/error', 'N/record', 'N/file'],
function(error, record, file) {
...
});
|
|
Code organization and structure
|
-
Good code is well organized. Data and operations in each function or class fit together. Organize your code into reusable chunks. Many functions can be used in a variety of forms. Any reusable functions should be stored in a common library file and then called into specific event functions for the required forms as needed.
-
Good code is written using small, readable, reusable functions. Including too many lines of code in one function makes it harder to understand and debug. Consider refactoring your code to keep all functions reasonable in size.
-
Use nesting judiciously. Extensive nesting may make your script unreadable. Try to keep your scripts as readable as possible.
-
During script development, use components, load them individually and then test each one -- inactivating all but the one you are testing when multiple components are tied to a single user event.
|
|
Naming conventions
|
Good code uses meaningful naming conventions. A well written script containing descriptive names for functions, variables, IDs, provides a good structure for building comments around.
Functions:
-
Although you can use any desired naming conventions for functions within your code, you should use custom name spaces or unique prefixes for all your function names.
-
When working with the top-level NetSuite functions in Client SuiteScript (for example the pageInit function), you should name the new function to correspond to the NetSuite name. For example, a pageInit function can be named pageInit or formAPageInit. If your code is already established, you can wrap it with a top-level function that has the appropriate naming convention.
-
Function Names: All function names should be written in lower camel case which means the first letter of each word (except the first) is capitalized.
-
For IDs, enter all record, field, sublist, tab, and subtab IDs in lower case in your SuiteScript code. Prefix all custom script IDs and deployment IDs with an underscore (_).
Variables and Constants:
-
Avoid using a single character as a variable name.
-
Name your variables to identify the data type and describe the data stored in the variable. For example,
-
String variables – prefix with "st", such as stTitle
-
Integer variables – prefix with "int", such as intTotalCount
-
Float variables – prefix with "fl", such as flPrice
-
Boolean variables – prefix with "b", such as bIsDone
-
Array variables – prefix with "arr", such as arrPhoneCalls
-
Object variables – prefix with "Obj", such as ObjNewPet
-
Record variables – prefix with "rec", such as recCustomer
-
Date variables – prefix with "dt", such as dtFirstBillingDate
-
Local variable scope is only within the function. Use standard camelCase naming.
-
Global variable scope is within the whole file or more files if declared under included library. Use a variable in upper case spaced by underscore.
-
To represent a pseudo constant, use a variable in upper case spaced by underscore. Constants are to be used to make code more readable.
IDs:
-
For IDs, enter all record, field, sublist, tab, and subtab IDs in lower case. Prefix all custom script IDs and deployment IDs with an underscore (_).
File names:
-
If you write SuiteScript code for multiple accounts, consider using the following file name convention: <Company Name/Abbreviation>_<Script Type>_<Requirement Description>.js. For example, MyCompany_CS_SetTaxable.js.
The following are suggested Script Types:
-
CS – client scripts
-
UE – user events
-
SL – Suitelet
-
RL – RESTlet
-
PL – Portlet
-
SC – Scheduled
-
MR – Map/Reduce
-
Gl – SuiteGL
-
WA – Workflow Action
-
MU – Mass Update
-
BI – Bundle Installation
|
|
Commenting
|
-
Thoroughly comment your code. Include comments about what the script is doing and who authored it. This practice helps with debugging and development and assists NetSuite Customer Support in locating problems, if necessary. It also helps anyone else who works with the script.
-
Write useful comments. Good code comments explain what is being done and why it is being done.
-
When documenting functions try to provide a good abstract of the actions of the function without restating the function name.
-
A good way to write relevant comments is to plan your scripts using pseudo code and replace the pseudo code with a relevant comment where necessary.
-
At a minimum, you should include comments: (1) for the file level disclaimer, (2) for version control, (3) at the function level, and (4) at the logic level.
-
Note that in SuiteScript 2.x, inline comments are not allowed within an object. You may not see a specific error, however, your script will not function properly if you include inline comments within an object.
|
|
White space and formatting
|
|
|
Using IDs
|
|
|
Passwords
|
|
|
Error and exception handling
|
-
Include proper error handling sequences in your script wherever data may be inconsistent, not available, or invalid for certain functions. For example, if your script requires a field value to validate another, ensure that the field value is available.
-
Use try-catch blocks. Try-catch blocks provide a way to “catch” an exception object thrown with the try block. As soon as an exception is thrown the catch block starts. An optional finally clause can also be used to run (guaranteed) if any exception occurs or not.
|
|
URLs
|
|
|
Date and Currency fields
|
|
|
Script parameters
|
-
Use script parameters or configuration files wherever possible, instead of hard coding values, to ensure that scripts can be configured easily
-
You can use the runtime.getCurrentScript() function in the runtime module to reference script parameters. For example, use the following code to obtain the value of a script parameter named custscript_case_field:
define(['N/runtime'], function(runtime) {
function pageInit(context) {
var strField = runtime.getCurrentScript().getParameter('SCRIPT', 'custscript_case_field');
...
});
-
For security reasons, do not include confidential information in script parameters. Information saved in script parameters can be indexed by search engines and therefore be viewable by the public. This means, for example, that the information could be found in Google searches. For more information, see Creating Script Parameters Overview.
|
|
Reserved words
|
|
|
Execution contexts
|
-
Consider the most appropriate script execution context for your script. The script execution context specifies how and when a script is triggered to execute. If you don’t use the appropriate context, blocks of scripts run when they shouldn’t and result in unexpected errors in the data and the script. For more information, see Execution Contexts.
|
|
Loading records
|
-
For record Create or Edit operations, you should load records in dynamic mode. This is required to make updates on record object.
Load records in a non-dynamic mode if you want to only get field values from the record and update on record is not needed.
-
Do not use record.load(options) to load a whole record when you only need to get the value of a few fields. The performance of the load record API is similar to loading the record in the user interface without field rendering since it loads all configuration fields and sublists for the record. To avoid slowing down the execution of the script, use search.lookupFields(options) to get the value of a few fields.
|
|
Invoking methods
|
-
You should use parameter id’s instead of parameter sequence.
-
You should use defined SuiteScript 2.0 native enums.
You may find the list of valid enums on Help and SuiteScript 2.0 API pdf.
|
|
Asynchronous programming
|
|
|
Custom code
|
|
|
Testing
|
-
Good code is well-tested. Testing serves as an executable specification of the code and examples of its use.
-
Always thoroughly test your code before using it on your live NetSuite data.
-
If the same script is used across multiple forms, ensure that you test any changes to the code for each form that the code is associated with.
-
During testing, the Deployment Status should be Testing to limit the script execution to only the script owner. If several users are testing a script (or if a Sandbox Account is being used), the Deployment Status can be set to Released, but you must be sure to choose the appropriate Audience so that the script does not execute for users who are not involved in the testing process. For production, the Deployment Status should set be Released. Again, it is critical to set the appropriate Audience so that the script does not execute for unintended users.
-
During testing, the Log Level should be set to Debug.
|
|
Logging
|
-
Log messages in the script should make business sense; include the record id, record type and other important details in your log messages. Each log message should provide a clear picture of the functionality that the script is designed to achieve.
-
Key steps in each script should be logged as Audit.
-
Proper logging adds to the readability of the code and also significant on issue/error debugging.
-
During testing, the Log Level should be set to Debug. For a Production Deployment, the Log Level should be set to Audit. Note that if there are production issues that require diagnosis/debugging, the Deployment Log Level can be set back to Debug.
|
|
Other
|
-
Consider the time zone that your scripts must use. By default, server scripts use the time zone that is specified in your NetSuite account. Be sure to convert your time values to the correct time zone before you use them, if necessary.
-
Consider field limits and translation when creating your scripts. Fields that use special characters used in some languages may support fewer characters than the field limit specified. For example, the Reference No. field (tranid) supports 45 English characters, but supports fewer Chinese characters.
-
Be sure to use BigInt values in your scripts to avoid potential errors. Integers larger than MAX_SAFE_INTEGER and smaller than MIN_SAFE_INTEGER must be enclosed in quotations or appended with 'n' at the end of the integer literal. For more information about BigInt values, see BigInt.
|