|
You must unlearn what you have learned. This article contains obsolete data. It reflects a Dark Brotherhood policy, position, or object that has been removed or replaced. It is preserved here for historical purposes only and should not be used/referenced.
|
Variable Declaration, Naming and Type Notation
- RULE
- Each variable should be dimmed and initialized at the start of the appropriate code section. “Option Explicit” should be declared at the very start of each .asp file. Variables should be commented to display their use.
- RATIONAL: Using Option Explicit forces the coder to dim variables before they are used. Dimming variables and initializing them to the proper values speeds up the processing of the page.
- RULE
- Use the Hungarian notation for naming variables and objects.
- RATIONAL: The purpose of the Hungarian notation is to be able to interpret the type and purpose of a variable without having to search through the code for its use.
EXAMPLES:
- RULE
- Use the Hungarian notation for form fields to make forms clearer
- RATIONAL: The purpose of the Hungarian notation is to be able to interpret the type and purpose of a field without having to search through the code for its use.
EXAMPLES:
- RULE
- Use all uppercase when declaring a const variable
- RATIONAL: Using all uppercase letters for constants helps to clearly indicate which variables are constants without referring to the declaration
EXAMPLE: Const MIN_USERS = 3
- RULE
- Variable names should be meaningful and descriptive.
- RATIONAL: Combined with the Hungarian notation, this leads to clear code, where the purpose and type of each variable is obvious from inspection.
EXAMPLES:
Good
|
Bad
|
strUserName
|
N
|
intUserId
|
uid
|
Code Documentation
- RULE
- Include a File Information section at the very top of you page, include File Author, Date Created, Description and Date / Description of any changes made to the code.
- RATIONAL: Documenting changes, the authors name and the date of the creation allow for easy understanding of and access to the author in the future.
- RULE
- Document all variables.
- RULE
- Document all conditional statements, explain what it is checking.
- RULE
- Document all functions, explaining what the function does and what it is returning.
- RULE
- Document all tricky and unusual code.
Code Structure and Practices
- RULE
- Avoid context switching such as switching between ASP and HTML or switching between VBscript and Jscript on the same page. Try to perform all server side code at the top of your page before executing any HTML code.
- RATIONAL': Switching between ASP and HTML causes a slow down in script processing time and leads to sloppy code. Forcing the ASP code at the top of the page requires planning and forethought from the coder.
- RULE
- Combine multiple "Response.Write" lines into one larger single statement whenever possible
- RATIONAL: Speeds up script processing times. Leads to cleaner code
- RULE
- Use arrays rather than dictionary objects or collections.
- RATIONAL: Arrays are always faster and more efficient than other storage methods and use less memory than dictionary objects or collections.
- RULE
- Indent blocks of code with an indent size of four (4) spaces
- RATIONAL: Indents allow for easier readability of code. Four spaces is an industry-standard indent.
- RULE
- Use white space to separate those blocks.
- RATIONAL: White space allows for easier readability of code
- RULE
- Put all file includes below the File Information comment block.
- RATIONAL: Having includes at the top of the page instantly allows the coder to see what the file is referencing and follows the dichotomy calling for ASP to be at the top of the page.
- RULE
- Declare all global variables below the file includes.
- RATIONAL: Global variables should be declared at the top of the file to increase ease of use and notice of what they are
- RULE
- Put the ASP delimiters <% %> on the left hand margin.
- RATIONAL: Allows for easier readability of code. Makes it easier to distinguish code blocks.
- RULE
- Use all lowercase when writing HTML tags
- RATIONAL: Allows for easier readability of code, lowers confusion with Database calls and Constant declarations.
- RULE
- Use “Sub” rather than “Function” for functions that have no return value
- RATIONAL: Subs are built to be used without returning a value. Using them in the place of functions increases code readability and processing speed.
- RULE
- Dim and fill variables for items pulled from the Request(“”) object rather than calling the Request(“”) object continuously.
- RATIONAL: Using variables filled from the Request(“”) Object allows for easier readability of the code, as the coder can document what the data being pulled from the object is. Continued use of variables is also faster to process than Request(“”) calls and less confusing.
Common Names and Customs