Script Coding Guidelines |
Active Web |
 |
|
Script Coding Guidelines |
Active Web |
|
This section provides some general guidelines for script developers.
Variable names should be lower case with upper case letters to separate words. Make your variable names descriptive (e.g. parameterCount is much more meaningful than x). Meaningful variable names make code much easier to understand.
Function names should follow the same convention as variable names. Make your function names describe the purpose of the function.
Get into the habit of always defining variables with the 'var' operator even when not in functions. This allows you to move code into a function without having to worry about variables being overwritten.
Functions should be short and do one thing. Look for repetitive code and put it in a function.
The input arguments to a function should not, in general, be modified inside the function. This is because the arguments are often passed by reference rather than by value, so modifying an argument inside a function can change its value outside the function.
All variables created inside functions must be declared with the var operator before or during, their first use. This makes sure that a function does not inadvertently use a variable from outside the function.
Functions should not use the write statement; they should instead return a string of write data. This is because functions can be reused and by using the write statement they are limited so that they can only be used at defined places in the script page. Not using the write statement makes functions more flexible.
Code should be formatted using tabs rather than spaces. This makes the formatting of shared code more reliable.
Use the ScriptDoc comments (see Documenting your Code) before functions so that others know what the function is doing. Define the function arguments and function return using the @param and @return tags so that others can understand your code.
One major area that can have an impact on performance is building large strings. Large strings are processed more slowly than strings put in the output buffer so it is more efficient to do multiple 'write' statements rather than building up a large string and doing a single 'write' statement. When using functions you must make the choice between flexibility (using strings) and performance (using 'write' statements). Building up a large string using the + or += operators is particularly inefficient as each statement creates a new copy of the string.
Both Libraries and include files can be replaced by Fragments. Fragments provide a much more flexible way of reusing code.
In Fragments only declare public (this is usually done in the constructor function) those functions that need to be accessed from outside the fragment.
All XML configuration files should have a suffix of '.xool' not '.xml'. This is because the '.xml' suffix is used for XML scripts and files with this suffix will be compiled by the Active Web compiler.
Don't embed configuration data (this includes file names) in the code. Put your configuration data in the project.ini file or place it as a variable in a Fragment or a properties file so that each configuration property is only defined once in your whole application.
Topic ID: 150093