Home | Web Design | Programming | Fairlight CMI | Soap Box | Downloads | Links | Biography | About... | Site Map |
CA-CLIPPER CODING GUIDELINES |
CA-Clipper | Opportunities | Tips and Tricks | Networking | Internal Errors | Source Code | CA-VO |
BACK TO CA-CLIPPER PROGRAMMING |
Language Syntax The general rule of thumb is: built-in features in lowercase, and custom-written functions in mixed case. When specifying the complete syntax of a language element in documentation, the input items, parameters, and so on are referred to using the following symbols:
dnLower and dnUpper can be either date or numeric:
|
Filenames and Aliases All filenames, in any context, are in upper case. Filenames follow DOS naming conventions (preferably limited to letters, numbers, and the underscore).
e.g. "A program is stored in a text file with a .PRG extension." Alias names follow the same conventions as filenames, but are limited to A-Z, 0-9, and the underscore. If a filename begins with a number or contains unusual characters, an alias must be specified when the file is opened or an error will result. Note that CA-Clipper does not natively support Windows 95 long filenames, although third-party libraries are available to add the capability. |
Fieldnames Fieldnames are all uppercase, and always include the alias of the table. Fieldnames may contain underscores, but should not begin with one (because the underscore is generally used to indicate an internal symbol).
|
Memory Variables Memory variables consist of a lowercase type designator followed by a mixed case description (see Hungarian Notation). Although CA-Clipper only recognizes the first 10 characters as unique, variable names may be longer.
|
Commands, Functions, and Keywords All built-in commands, functions, and keywords are lowercase. In documentation, the font should be Courier or a similar font. If fonts are not available, then bold or CAPITALIZE the word for emphasis. Never use abbreviations -- this practice is not necessary with a compiler, although it was common in the early days of dBase (which was an interpreter). There should never be a space between the function name and the opening parenthesis. Also, note that the iif() function
should never be spelled if() .
... ) and do not include the
to clause, unless it is followed by the file ,
print , or screen keywords.
|
Programmer-Defined Functions & Procedures These begin with an uppercase letter, followed by mixed case letters as appropriate.
return statement per
function or procedure, and it should not be indented.
|
Preprocessor Directives Preprocessor directives are lowercase and are preceded by the # sign.
|
Declarations Local variables are grouped according to functionality, and may be declared on one or more lines. The declarations appear as the first code at the beginning of a function or procedure.
|
Logicals The .T. and .F. are typed in uppercase.
|
Operators The in-line assignment operator ( := ) is used for all
assignments, and the exact comparison operator (== ) is used
for all comparisons.
+= ,
-= , *= , etc.) are convenient, they should
not be used if readability suffers.
++ ) and decrement (-- ) operators
are convenient, but can lead to obscure code because of the difference
between prefix and postfix usage.
|
Spacing Whenever a list of two or more items is separated by commas, the commas are followed by a space.
nX := " would find the lines where an
assignment is made, while searching for "nX:= " would find
the declaration line (such as the local above).
|
Indentation Indenting control structures is one of the easiest techniques, yet it improves the readability the most. Indent control structures and the code within functions and procedures 3 spaces.
|
Tabs Do not use tabs in source code -- insert spaces instead. Tabs cause problems when printing or when moving from one editor to another, because of the lack of a standard tab width between editors and printers. Typically, printers expand tabs to 8 spaces which easily causes nested control structures to fall off the right-hand side of the page. Commonly, a source code editing program will insert the appropriate number of spaces when the <TAB> key is hit. |
Line Continuation When a line of code approaches the 80th column, interrupt the code at an appropriate spot with a semicolon and continue on the next line. Indent the line so that it lines up in a readable manner.
|
Quotes Use double quotes for text that needs to be translated (will appear on the screen), and single quotes for other strings.
|
Comments Comments are structured just like English sentences, with a capital letter at the beginning and a period at the end.
// ' of in-line comments begins at column 40,
if possible. This leaves enough room for a useful comment.
|
Home | Web Design | Programming | Fairlight CMI | Soap Box | Downloads | Links | Biography | About... | Site Map |
Send comments about this site to Greg at
gregh@ghservices.com All pages copyright © 1996-1999 GH Services Created 1996/10/01 Last updated 1999/09/30 All trademarks contained herein are the property of their respective owners |