INTRODUCTION
Naming conventions describe stylistic formats and general naming techniques to apply when naming inputs/outputs, aliases, constants, etc. Some conventions discuss stylistic formats, useful for quick recognition of which entity type a given name represents, while others describe general issues such as optimum length, types of words to use, acceptable abbreviations, etc.
CHOOSING A NAME IN GENERAL
#1 Consideration: The name must fully and clearly describe the entity it is representing. It should be easy to read and easily understood by anyone looking at your code.
Try to use non-technical terms: The name should describe the entity as an object in the real world rather than a computer-specific technical term (i.e. stack, queue, input, output, struct, etc.).
Optimum length: Somewhere in the ballpark of 9 - 16 characters. This is not by any means an absolute rule, but rather a guideline. Most names require about this length in order to clearly describe the entity they represent, but some can be fully descriptive in a few letters while others might actually take more than 16 characters.
FORMATTING NAMES TO INDICATE THE ENTITY THEY REPRESENT
Inputs/Outputs: In general, you should have no control over this as the homework assignment usually dictates such. When you do have the opportunity to choose, use the convention used for aliases.
Aliases: These should begin with a lowercase letter. If the alias represents includes multiple words, any words after the first should be capitalized. No underscore ‘_’ characters should be used (i.e. aliasName). Use an alias for each input and output with an undescriptive names (professors often pick such names to make the problems harder) and then use another alias for each group of related aliases (ie. s3..s0 -> Sum3..Sum0 -> Sum = [Sum3..Sum0])
Macro inputs: These should be formatted like aliases except that the first word of each macro input will be "mi". This is because we will often be using macros for assigning values to aliases and so we want to use an input name as close to the alias as possible while still being different. Since macro input naming should be for the most part just modifying an alias name, it should be very straightforward (i.e. aliasName -> Macro = miAliasName). See the page on Macros for more information.
Macros: Although ABEL does not support functions, it does support macros. Macros should be named like aliases except that the first letter should be capitalized (i.e. MacroName).
Constants: These should be all in uppercase with words separated with one underscore ‘_’ character (i.e. CONSTANT_NAME).
Enumerations: Although ABEL does not directly support enumerations, we can simulate them by means of a naming convention. Enumerations should be named like constants with the exception that all enumerations of a given object should share the object’s name as their prefix, which should be followed by an underscore (i.e. an enumeration for colors might have members named "COLOR_YELLOW", "COLOR_GREEN", "COLOR_WHITE", etc.).
Abbreviations: No abbreviations for words are to be used except those anyone would recognize (i.e. miles per hour = mph), an enumeration prefix, or those contained in the list which follows (this section is particularly welcoming to suggestions for other useful abbreviations). This is to make ensure that all names are easily understood by TAs and your peers.
EXAMPLES
Good Names Bad Names ---------------- ------------------------------------ alias: trainSpeed s, ts, train, trainS, x macro input: miTrainSpeed (no other options available) macro: ALUOutput A, ALU, AOut, AOutput, Xx constant: LINES_PER_PAGE L, LPP, LINES, X_X enumeration: CTRL_INCR C, I, C_I, CTRL_I, CTRL_INC, CTRL_X