Coding Standards

Coding standards

####very important, please read before you contribute to ExecutiveMan Good coding standards are important in any development project, but particularly when multiple developers are working on the same project. Having coding standards helps ensure that the code is of high quality, has fewer bugs, and is easily maintained.

• Indentation Use an indent of 1 tab for each level of indent, with no spaces. This way, each developer can set their preferred visible tab width in their own editor.
• Maximum Line Length Code lines shouldn't be too long. Content lines can be as long as necessary (use soft-wrap).
• Classes Class names must start with a capital letter. If a class name is comprised of more than one word, the first letter of each new word must be capitalized.
• Class Declaration Classes must be named by following the naming conventions. The brace is always written on the same line as the class name. Every class must have a documentation block that conforms to the JSDoc standard. Any code within a class must be indented one tab. Only one class is recommended per JS file.
• Class Member Variables Any variables declared in a class must be listed at the top of the class, prior to declaring any functions.
• Filenames Only alphanumeric characters, underscores, and the dash character ("-") are permitted. Spaces and are prohibited.
• Functions and Methods Function names may only contain alphanumeric characters. Underscores are not permitted. Numbers are permitted in function names but are discouraged. Function names must always start with a lowercase letter. When a function name consists of more than one word, the first letter of each new word must be capitalized. This is commonly called the "camelCaps" method. Verbosity is encouraged. Function names should be as verbose as is practical to enhance the understandability of code. Functions in the global scope ("floating functions") are permitted but discouraged. It is recommended that these functions should be wrapped in a "static" class.
• Function and Method Declaration Like classes, the brace is always written on the same line as the function name. There is no space between the function name and the opening parenthesis for the arguments. Every function must have a documentation block that conforms to the JSDoc standard.
• Function and Method Usage Function arguments are separated by a single trailing space after the comma delimiter, with no space before or after the opening parenthesis, and no space before or after the closing parenthesis. For example: threeArguments(1, 2, 3);
• Variables Like function names, variable names must always start with a lowercase letter and follow the "camelCaps" capitalization convention. Verbosity is encouraged. Variables should always be as verbose as practical. Terse variable names such as "i" and "n" are discouraged for anything other than the smallest loop contexts. If a loop contains more than 20 lines of code, the variables for the indices need to have more descriptive names.
• Constants Constants may contain both alphanumeric characters and the underscore. Numbers are permitted in constant names. Constants must always have all letters capitalized. To enhance readablity, words in constant names must be separated by underscore characters.
• String Literals When a string is literal (contains no variable substitutions), the apostrophe or "single quote" must always used to demarcate the string.
• Control Statements Control statements based on the if and else if constructs must have a single space after the "if" or "else if" and before the opening parenthesis of the conditional. Within the conditional statements between the parentheses, operators must be separated by spaces for readability. Inner parentheses are encouraged to improve logical grouping of larger conditionals. The opening brace is written on the same line as the conditional statement. "else if" statements are written on the same line as the closing brace for the previous "if" or "else if" statement. The final closing brace is always written on its own line. Any content within the braces must be indented one tab.
• Switch Control statements written with the "switch" construct must have a single space after the opening "switch" of the conditional statement.
• Comments What you found clever, another developer may find unreadable. Please explain your clever code. If you are unsure of something, a comment stating so is good to have. If you think you did something "hacky", that's probably worth commenting about as well.
• Commented Out Code Commented out code is greatly discouraged. Since the system is under version control, deleted code can always be easily retrieved. The only time commented out code is allowed is when it is being used to describe a usage example. Otherwise it should be deleted prior to check in.