Coding Guidelines and Standards
General Guidelines
Avoid elusive names that are open to subjective interpretation, such as Analyze() for a routine, or xxK8 for a variable. Such names contribute to ambiguity more than abstraction.
In languages that permit function overloading, all overloads should perform a similar function. For those languages that do not permit function overloading, establish a naming standard that relates similar functions.
When naming elements, avoid using commonly misspelled words. Also, be aware of differences that exist between American and British English, such as color/colour and check/cheque.
Despite the availability of external documentation, source code listings should be able to stand on their own because hard-copy documentation can be misplaced.
External documentation should consist of specifications, design documents, change requests, bug history, and the coding standard that was used.
Formatting
Indenting and white space shall be used to make the code more readable, like the paragraphs of a book.
No more that one statement shall appear on a single line.
Use the continuation character to split long lines to make them more readable. The continuation lines shall be indented.
Comments
Comments shall specify what the purpose of the code is, not simply repeat the code.
All deviations from coding standards or good programming practice shall have a comment specifying the reasons why.
Comments shall be indented to the same level as the code that follows them.
End-of-line comments shall be avoided, the exception being in the declaration section if a comment for a variable declaration is required.
Comments shall be specified with a apostrophe not with the antiquated Rem statement.
Solid comment lines (for instance '********) are not to be used except in module or procedure boilerplates.
Document all decision and loop structures.
Variables
Constants are coded in ALL_UPPER_CASE with words separated by underscores.
Constants shall always be used in place of 'magic numbers', the exception to this being the initialisation of variables to 0 or 1 (i.e. initialising a loop counter).
Variables shall have a focused use. They should not be declared once and used for several different purposes.
Append computation qualifiers (Avg, Sum, Min, Max, Index) to the end of a variable name where appropriate.
Use customary opposite pairs in variable names, such as min/max, begin/end, and open/close.
In object-oriented languages, it is redundant to include class names in the name of class properties, such as Book.BookTitle. Instead, use Book.Title.
Since most names are constructed by concatenating several words together, use camel casing (documentFormatType) where the first letter of each word except the first is capitalized.
Avoid using terms such as Flag when naming status variables, which differ from Boolean variables in that they may have more than two possible values. Instead of documentFlag, use a more descriptive name such as documentFormatType.
Even for a short-lived variable that may appear in only a few lines of code, still use a meaningful name. Use single-letter variable names, such as i, or j, for short-loop indexes only.
It is sometimes useful to include notation that indicates the scope of the variable, such as prefixing a g_ for global variables and m_ for module-level variables.
Begin groups of enumerated types with a common prefix, such as FONT_ARIAL and FONT_ROMAN.
Avoid using typographical marks to identify data types, such as $ for strings or % for integers.
Procedure Naming
Procedure names shall have mixed case descriptive names where the initial character of each word is in upper case. The names shall only exceptionally contain abbreviations, and where abbreviations are used they shall be used consistently throughout the application.
Use the verb-noun method for naming routines that perform some operation on a given object, such as CalculateInvoiceTotal().
Procedure Length
There has been an urban myth in programming academia that short procedures of no more than "a page" (whatever that is) are better. Actual research has shown that this is simply not true. There have been several studies that suggest the exact opposite.
To summarize, hard empirical data suggests that error rates and development costs for routines decreases as you move from small (<32 lines) routines to larger routines (up to about 200 lines). Comprehensibility of code (as measured on computer-science students) was no better for code super-modularised to routines about 10 lines long than one with no routines at all. In contrast, on the same code modularised to routines of around 25 lines, students scored 65% better.
What this means is that there is no sin in writing long routines. Let the requirements of the process determine the length of the routine. If you feel that this routine should be 200 lines long, just do it. Be careful how far you go, of course. There is an upper limit beyond which it is almost impossible to comprehend a routine. Studies on really BIG software, like IBM's OS/360 operating system, showed that the most error prone routines were those over 500 lines, with the rate being roughly proportional to length above this figure.
Of course, a procedure should do ONE thing. If you see an "And" or an "Or" in a procedure name, you are probably doing something wrong. Make sure that each procedure has high cohesion an low coupling, the standard aims of good structured design.
Perl
Read perldoc perlstyle and follow all suggestions contained therein, except where they disagree with the general coding standards, which take precedence.
Use the -w command line flag and the strict pragma at all times, and -T (taint checking) where appropriate.
Use the 'use strict' directive.
Name Perl scripts with a .pl extension, and CGI scripts with a .cgi extension.j
Visual Basic
Always use Option Explicit!
System constants and enumerations shall be used wherever possible, for example, vbMinimized.
Constants shall be used when referring to elements in a control array, for example, txtName(FIRST_NAME).Text
Always include a Case Else in Select Case structures.
Use upper case letters for GoTo labels.
Use GoTo only where it improves readability.
Do not use GoSub.
Do not use default properties, rather specify them explicitly, for example txtName.Text = sName
Error Handling
Unless you are absolutely sure that a routine does not need an error handler, you should at the very least create a handler around the entire routine.
Resume Next is not error handling, unless you expect an operation to raise an error and will check for it.
Variables
Variables shall be declared at the narrowest scope possible. Global scope modules are to be avoided.
Local variables shall be declared at the top of a procedure, not within the body.
The Variant type shall only be used when no other more specific type is possible.
String variables shall be concatenated with the ampersand character (i.e. & not +)
Variables shall be EXPLICITLY typed.
Procedures
Procedures shall have an appropriate EXPLICITLY defined scope (Public, Private or Friend) and not rely on the default setting.
Procedures shall have as few exit points as possible; Exit Function/Sub and Property are to be avoided unless it improves the readability.
Procedures shall have robust exit code where object references are explicitly tidied up rather than relying on Visual Basic to clean up as they go out of scope.
Parameters shall have a specified data type.
Data will be passed to and from procedures with parameters rather than module or global scope variables.
Parameters with a small range of values shall be declared with an enumeration type.
Where parameters are not to be changed they shall be declared ByVal unless there is some performance reason to declare them ByRef.
References
A Microsoft Coding Standards Article