Our guidelines

Names
The naming scheme is one of the most influential aids to understanding the logical flow of an application. A name should tell "what" rather than "how".

Routines
-
Avoid elusive names that are open to subjective interpretation, such as AnalyzeThis() for a routine, or xxK8 for a variable. Such names contribute to ambiguity more than abstraction.
-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.
-Use the verb-noun method for naming routines that perform some operation on a given object, such as CalculateInvoiceTotal().
-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.

Variables
-Append computation qualifiers (Avg, Sum, Min, Max, Index) to the end of a variable name where appropriate.
-Use complementary pairs in variable names, such as min/max, begin/end, and open/close.
-Since most names are constructed by concatenating several words, use mixed-case formatting to simplify reading them.
In addition, to help distinguish between variables and routines, use Pascal casing (CalculateInvoiceTotal) for routine names where the first letter of each word is capitalized. For variable names, use camel casing (documentFormatType) where the first letter of each word except the first is capitalized.
-Boolean variable names should contain Is which implies Yes/No or True/False values, such as fileIsFound.
-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.
-Do not use literal numbers or literal strings, such as For i = 1 To 7. Instead, use named constants, such as For i = 1 To NUM_DAYS_IN_WEEK for ease of maintenance and understanding.

Tables
-When naming tables, express the name in the singular form. For example, use Employee instead of Employees.
-When naming columns of tables do not repeat the table name; for example, avoid a field called EmployeeLastName in a table called Employee.
-Do not incorporate the data type in the name of a column. This will reduce the amount of work should it become necessary to change the data type later.

Miscellaneous
- Minimize the use of abbreviations, but use those that you have created consistently. An abbreviation should have only one meaning and likewise, each abbreviated word should have only one abbreviation. For example, if you use min to abbreviate minimum, do so everywhere and do not use min to also abbreviate minute.
-When naming functions, include a description of the value being returned, such as GetCurrentWindowName().
-File and folder names, like procedure names, should accurately describe their purpose.
-Avoid reusing names for different elements, such as a routine called ProcessSales() and a variable called iProcessSales.
-Avoid homonyms, such as write and right, when naming elements to prevent confusion during code reviews.
-When naming elements, avoid commonly misspelled words. Also, be aware of differences that exist between regional spellings, such as color/colour and check/cheque.
-Avoid typographical marks to identify data types, such as $ for strings or % for integers.