Naming conventions

From Rosetta Code
Naming conventions
You are encouraged to solve this task according to the task description, using any language you may know.

Many languages have either (or both) de-facto naming conventions or de-jure naming conventions for names used in the language and/or its libraries. These may take the form of prefixes, suffixes or a combination of upper-case and lower-case characters. Often the conventions are a bit haphazard, especially where the language and/or library has gone through a periods of evolution. (In this case: give a brief example and description).

Document as best you can (with simple examples where possible) the evolution and current status of these naming conventions. For example, name conventions for:

  • Procedure and operator names. (Intrinsic or external)
  • Class, Subclass and instance names.
  • Built-in versus libraries names.

If possible, indicate where the naming conventions are implicit, explicit, mandatory or discretionary. Any tools that enforced the the naming conventions. Any cases where the naming convention as commonly violated.

If possible, indicate where the convention wased use to hint at other issues, for example the C standard library uses a prefix of "_" to "hide" raw Operating System calls from the non systems-programmer. Whereas Python embeds member functions in between "__" to make a member function "private".

See also

360 Assembly[edit]

No real naming conventions for S/360 Assembler except the stric rule for names (called symbols).
A symbol may contain from one to six characters; the characters may be any combination of alphabetic (A through Z) and numerical (O through 9) characters. The first character must be alphabetic. Special characters and embedded blanks must not be used in symbols.

ALGOL 68[edit]

In the Formal Specification

The revised report used "shorthand" to indicate an MODE was "private" to the language specification. The character ℒ was used to indicate that the name could be repeated for every precision... e.g. ℒ INT could mean: ... SHORT SHORT INT, SHORT INT, INT, LONG INT, LONG LONG INT etc and ℓ cos could mean: short short cos, short cos, cos, long cos, long long cos etc.

PROCcos = (REAL x)REAL: ¢ a ℒ real value close to the cosine of 'x' ¢;
PROC ℓ complex cos = (COMPL z)COMPL: ¢ a ℒ complex value close to the cosine of 'z' ¢;
PROCarccos = (REAL x)REAL: ¢ if ABS x ≤ ℒ 1, a ℒ real value close
to the inverse cosine of 'x', ℒ 0 ≤ ℒ arccos (x) ≤ ℒ pi ¢

For LONG LONG MODEs this would be coded as:

PROC long long cos = (LONG LONG REAL x) LONG LONG REAL: ¢ a ℒ real value close to the cosine of 'x' ¢;  
PROC long long complex cos = (LONG LONG COMPL z) LONG LONG COMPL: ¢ a ℒ complex value close to the cosine of 'z' ¢;
PROC long long arccos = (LONG LONG REAL x) LONG LONG REAL: ¢ if ABS x ≤ ℒ 1, a ℒ real value close
to the inverse cosine of 'x', ℒ 0 ≤ ℒ arccos (x) ≤ ℒ pi ¢

Note: The type returned by the procedure is generally prefixed to the procedure name.

Standard language

Because Algol68 was required on 6-bit and 7-bit, but could take advantage of wide character sets the naming convention could be mechanically varied across platforms. In a 7-bit environment reserved words, modes and operators were typically upper-case. Constants, variable and procedure names were typically lower-case.

The more peculiar convention was for reserved words, modes and operators was for these to appear in code as bold typeface or even underlined when published.

For example:

Algol68 "strict"
as typically published
¢ underline or 
  bold typeface ¢
mode xint = int;
xint sum sq:=0;
for i while
  sum sq≠70×70
  sum sq+:=i↑2
Quote stropping
(like wikitext)
'pr' quote 'pr'
'mode' 'xint' = 'int';
'xint' sum sq:=0;
'for' i 'while'
sum sq70×70
sum sq+:=i2
For a 7-bit character code compiler
XINT sum sq:=0;
sum sq/=70*70
sum sq+:=i**2
For a 6-bit character code compiler
SUM SQ .NE 70*70
Algol68 using res stropping
(reserved word)
mode .xint = int;
.xint sum sq:=0;
for i while
sum sq70×70
sum sq+:=i2

Note that spaces are permitted in constants, variable and procedure names.

Various other prefixes and suffixes (grouped by type function) can be found in the standard prelude:

To query file capabilities standard file and channels file procedures Exception handling procedures Implementation specific precisions mode limits and sizes special 'characters
  • get possible
  • put possible
  • bin possible
  • reset possible
  • set possible
  • reidf possible
  • stand in
  • stand out
  • stand back
  • stand in channel
  • stand out channel
  • stand back channel
  • print, write, put, read, get
  • printf, writef, putf, readf, getf
  • print bin, put bin, read bin, get bin
  • print ℓ int, put ℓ int, read ℓ int, get ℓ int
  • print ℓ real, put ℓ real, read ℓ real, get ℓ real
  • etc
  • on logical file end
  • on physical file end
  • on line end
  • on page end
  • on format end
  • on value error
  • on open error
  • on transput error
  • on format error
  • int lengths
  • int shorths
  • real lengths
  • real shorths
  • bits lengths
  • bits shorths
  • bytes lengths
  • bytes shorths
  • ℓ bits width
  • ℓ bytes width
  • ℓ int width
  • ℓ real width
  • ℓ exp width
  • ℓ max int
  • ℓ max real
  • ℓ small real
  • error char
  • exp char
  • formfeed char
  • newline char
  • null character
  • tab char




# Field names begin with $ so $1 is the first field, $2 the second and $NF the
# last. $0 references the entire input record.
# Function and variable names are case sensitive and begin with an alphabetic
# character or underscore followed by any number of: a-z, A-Z, 0-9, _
# The awk language is type less; variables are either string or number
# depending upon usage. Variables can be coerced to string by concatenating ""
# or to number by adding zero. For example:
# str = x ""
# num = x + 0
# Below are the names of the built-in functions, built-in variables and other
# reserved words in the awk language separated into categories. Also shown are
# the names of gawk's enhancements.
# patterns:
# actions:
# break continue delete do else exit for if in next return while
# case default switch (gawk)
# arithmetic functions:
# atan2 cos exp int log rand sin sqrt srand
# bit manipulation functions:
# and compl lshift or rshift xor (gawk)
# i18n functions:
# bindtextdomain dcgettext dcngettext (gawk)
# string functions:
# gsub index length match split sprintf sub substr tolower toupper
# asort asorti gensub patsplit strtonum (gawk)
# time functions:
# mktime strftime systime (gawk)
# miscellaneous functions:
# isarray (gawk)
# variables:
# function definition:
# func function
# input-output:
# close fflush getline nextfile print printf system
# pre-processor directives:
# @include @load (gawk)
# special files:
# /dev/stdin /dev/stdout /dev/error


BASIC is case-insensitive, although keywords are generally written entirely in uppercase.

A variable or function can have a suffix to indicate the type (which types are available depending on what implementation is in use): ! for single-precision, @ for fixed-point, # for double-precision, $ for strings, % for short integers, & for long integers.

It is also possible to use DEFtype commands to make the type of the variable to be based on what the first letter is (similar to FORTRAN). The default for Microsoft BASIC is: DEFSNG A-Z


Commands and keywords have to be entered in upper case. Variable names are case-sensitive: FOO, Foo, and foo are all different variables. Further, the same name can be used with different suffixes to refer to variables of different types: foo is a float, foo% is an integer, foo$ is a string, foo() is an array of floats, etc. There is nothing to prevent all these names being used in the same program.

The names of user-defined functions (which return exactly one value) and procedures (which may have no return value, or one, or several) must begin with FN or PROC, respectively. Many users find it convenient to follow this prefix with an underscore—so a procedure that takes a float, an array of strings, and an integer and then returns two integers might be defined as follows:

DEF PROC_foo(bar, baz$(), quux%, RETURN fred%, RETURN jim%)

Names like PROCfoo and FNbar are sometimes used, and even PROCFOO and FNBAR are entirely legal; but they are probably less readable.

TitleCase and camelCase are not much used in BBC BASIC, perhaps not used at all; lower_case_with_underscores is preferred for long names. In general, using lower case for user-defined names helps maintain a visual contrast with reserved words and the names of system variables.

The twenty-six integer variables A% to Z% (capitalized) are 'static': that is to say, they persist throughout an interpreter session and are unaffected by the commands NEW and CLEAR. They can thus be used to pass a small amount of data from one program to another.

If the first line of the program is a comment line of the form REM >myprog, the SAVE command can be used with no filename and the program will be saved as (in this case) myprog. Otherwise, it would be necessary to use SAVE "myprog".


Base language
  • All reserved words and operators are lower-case. e.g. while, for, if, sizeof and return etc.
Constants that appear in C "header" files are typically in upper-case:

Note also that there are remnants of some historic naming conventions in C where constants were required to be 8 characters or less. The "O_CREAT" constant is an example.

Types are often suffixed with a "_t", e.g. size_t, and "private" types and arguments are prefixed with "__":

extern size_t fwrite (__const void *__restrict __ptr, size_t __size,
size_t __n, FILE *__restrict __s) __wur;

However there are some instances where types use all upper-case. The classic is the type FILE.

In C, the standard library for floating point is focused on double precision, hence the function "cos" is for double precision, and a suffix of "f" and "l" indicate single precision and quad precision respectively.

#include <math.h>
double cos(double x);
float cosf(float x);
long double cosl(long double x);

Whereas for complex variable a prefix of "c" is added.

#include <complex.h>
double complex ccos(double complex z);
float complex ccosf(float complex z);
long double complex ccosl(long double complex z);

This prefix/suffix convention extends to other standard c library function, for example in the following the "f" suffix indicates that an argument is a format string, the prefixes of "s", "v" and "n" hint at other argument types:

#include <stdio.h>
int printf(const char *format, ...);
int fprintf(FILE *stream, const char *format, ...);
int sprintf(char *str, const char *format, ...);
int snprintf(char *str, size_t size, const char *format, ...);
#include <stdarg.h>
int vprintf(const char *format, va_list ap);
int vfprintf(FILE *stream, const char *format, va_list ap);
int vsprintf(char *str, const char *format, va_list ap);
int vsnprintf(char *str, size_t size, const char *format, va_list ap);

The Unix C standard library uses a prefix of "_" to "hide" raw Operating System calls from the non systems-programmer


- All keywords are lowercase (mandatory)
- Names of parameters and (private) fields should be camelCase.
- Names of anything else should be PascalCase.

Possible exception are methods that are automatically generated by a tool.
For example, the Visual Studio Gui designer will generate names of event handlers based on the variable name: submitButton_Clicked

- Names of enums should be plural if it's a flags enum, otherwise it should be singular.

public enum Planet {
Mercury, Venus, Earth, Mars, Jupiter, Saturn, Uranus, Neptune
public enum Days {
None = 0,
Sunday = 1,
Monday = 2,
Tuesday = 4,
Wednesday = 8,
Thursday = 16,
Friday = 32,
Saturday = 64,
Workdays = Monday | Tuesday | Wednesday | Thursday | Friday
AllWeek = Sunday | Saturday | Workdays

You should:
- prefix interface names with I e.g. IPrinter

- prefix generic type parameters with T e.g.
Dictionary<TKey, TValue>
most of the time, a single T is sufficient e.g.

- postfix type names that inherit from EventArgs, Exception, Attribute and EventHandler e.g. MouseMoveEventArgs
- postfix async method names with Async e.g. GetDataAsync()

You should NOT use:
- underscores, hyphens or any other nonalphanumeric characters
- hungarian notation

Common Lisp[edit]

  • The language's names are first-class Symbols. (ie: a variable is the value-binding given to a Symbol; a named function is a function object that is bound as the function-value of a symbol; etc.) As a Lisp-2, the various bindings of a symbol (value, function, class name, package, etc.) occupy their own namespaces; eg, the symbol named LIST can refer at once to the type LIST, the function LIST (to create a list), and is often used as a variable containing some particular list.
  • Symbol names can contain any characters in Unicode, but for most common purposes it's traditional to limit the characters to those that can be entered without quoting (with “|”) the symbol. Usually, names are restricted to a…z 0…9 - / + = < > . ! $ % & ? * ~ — although only a-z 0-9 - are often used.
  • Using abbreviations is generally frowned-upon, at least in public (exported) symbols, unless they're quite common ones (eg: HTTP)
  • Functions and variable names are usually entered in source code as lowercase-with-hyphens phrases.
    • Depending on the environment, these are usually interned as symbols with all-upper-case names. Unquoted symbol-names are case-insensitive: list, List, and LIST (or liST, etc) are identical, but |list| and |LIST| are different from one another. In most environments, list and List are interned the name as |LIST| — ie, the name of the Symbol object is "LIST". (Allegro's CL “modern” environment is case-sensitive and case-preserving, however.)
  • Functions to construct an object or structure of some kind are usually named “make-thing,” eg, the standard library function Make-Array.
  • Functions that have a side-effect are usually named in a “verb-phrase” form; eg, Format or Delete-File
  • Functions which alter a generalized “Place” using the SetF feature (eg: object slots, structure slots, and other things) usually have an “F” suffix. (Historically, the things defined in the standard as “Places” were called “Fields.”) eg: SetF itself, IncF, etc.
  • Reader (Accessor) functions that return an attribute of an object are usually a noun-like phrase; eg, the function “Symbol-Name” takes a symbol object and returns its name as a string: (Symbol-Name 'List) ⇒ "LIST" Those that act only upon a certain class may prefix the field name, with the class name; eg, “Char-Code” returns the Unicode value for a character (like reading the “code” field from a Character-class object). With the exception of the built-in class Character (abbreviated Char in function names in the standard library), the class name is normally spelled-out in full. While the hash-table accessor is called GetHash due to historical reasons, accessors generally do not have a “Get-” prefix.
    • The SetF-accessors for altering a place are usually named identically to the reader functions; eg, a reader function named Person-Surname would be matched to a writer function named (SetF Person-Surname). This is what is created automatically when using the DefClass macro's :Accessor option on object slots, or when defining slots in DefStruct.
    • Writer functions generally are only defined in terms of SetF writers, and almost never as separately-named functions.
  • Predicate functions (returning a generalized Boolean) are named for what they would return “true” for, with a “-P” suffix. For example, Wild-Pathname-P returns true if passed a pathname object with wildcards. If the predicate is a single word (no hyphens), then the “-P” is just “P” — eg, StringP. Predicate functions usually do not have a “is-” prefix, like they might in a language like Java.
  • Comparator functions for number objects are < <= = >= > /= — for other types, one would usually prefix the operator symbols with the name of the type; eg, Char= String< Timestamp/=. Note that equality is usually = (not ==) and not-equal is written /=.
  • Functions or variable names with “%” at the end are usually meant as “internal, unstable” functions. This is distinct from whether the symbol is made external to the package — although it would be unlikely you would export a function with a %-name.
  • Global/dynamic variables are named with “earmuffs,” ie, leading and trailing asterisks — eg, *Standard-Output*, *Query-IO*. Failure to do so will elicit compiler warnings in some compilers.
  • Constants are usually defined with leading and trailing + signs — eg +Some-Constant+ — a convention that was not followed in the Common-Lisp package itself (eg: MOST-POSITIVE-FIXNUM)
  • Macros that define a new type of thing are usually named Define-some-thing; if the name of the thing being defined is a single, non-hyphenated word, they may be just DefThing. eg: DefClass, Define-Condition, or Define-SetF-Expander. The first argument is usually the name of the thing to be defined (as a symbol).
  • Functions that signal conditions (eg, errors) alike to the standard Assert or Check-Type macros usually are named Assert-some-condition or Check-some-condition. In Emacs, these patterns will highlight the function name, as well. Likewise, functions that signal warnings may be named Warn-whatever.
  • Type names for errors or warnings usually explicitly have the word “warning” or “error” in the name, eg, Server-Unreachable-Error
  • Macros that establish a dynamic state and clean up after it are usually named With-some-context; eg, With-Open-File, With-Database-Connection. Usually, such a macro will take a first argument as a list like a normal function call, followed by &body, mimicking With-Open-File and the like.
    (defvar *language* :en
    "The language to use for messages (defaults to English)")
    (defmacro with-language ((language) &body body)
    "Locally binds *LANGUAGE* to LANGUAGE"
    `(let ((*language* ,language))
    (defgeneric complain% (language about)
    ;; The % indicates this is an “internal” implementation detail.
    (:method ((language (eql :en)) (about (eql :weather)))
    "It's too cold in winter"))
    (defun complain (about)
    "Complain about something indicated by ABOUT"
    (princ (complain% *language* about) *error-output*)
    (terpri *error-output*)
    (finish-output *error-output*)
    (defmethod complain% ((language (eql :es)) (about (eql :weather)))
    "Hace demasiado frío en invierno")
    (complain :weather)
    (with-language (:es)
    (complain :weather))
    (complain :weather)

    It's too cold in winter
    Hace demasiado frío en invierno
    It's too cold in winter
  • Function names ending in a * are minor variants of the same-named function without the star; eg, the standard Let and Let* special forms.
  • Keywords for keyword arguments tend to follow the names used in standard library functions when possible, or mimic the patterns of them. “Private” arguments that callers probably won't need/want to set are usually given non-keyword symbols as their names; eg
    (defun do-something (argument &key ((secret-arg secret) "default"))
    (format t "Argument is ~a, secret is ~a" argument secret))
    ;; Normal caller
    (do-something "Foo")
    ;; Special caller:
    (do-something "Foo" 'secret-arg "Bar")
  • Functions which operate on a subset selected by a predicate function usually have names ending in -If or -If-Not; eg, Remove-If-Not
  • When a System contains multiple Packages, and there is one “main” package with which users of the System would interact, the main package usually has the same name as the System; and the others often have names that indicate the system name and a “/”. For example, the system UIOP has a package UIOP, as well as packages like UIOP/Filesystem and UIOP/Stream.
  • Package names may follow the Java standard of reversed-top-level-domain prefixes; eg, com.example.product.package. Some tools, eg REPLs, may “hide” everything before the last “.” in the package name.
  • Functions that may coërce something into a different type are often named Ensure-Type-Name. eg: (defun ensure-string (object) (princ-to-string object)) It's typical to make these a function that can accept any (reasonable) type, or a generic function that can specialize on various types.
    • Coërcion or conversion functions that explicitly change something from type “a” to type “b” are usually named one of these patterns: a->b, b<-a, b-from-a, or a-b. The last form, with just a hyphen, mimics the standard functions code-char and char-code, but is a bit more ambiguous.
  • The name _ (and sometimes names like __ or _2 are sometimes used to indicate ignored values for which a more meaningful name isn't available; for example, skipping an always-blank field in input records. There's nothing “magical” about the name, though; you still need to (declare (ignore _)), so using a more meaningful name is usually preferred. _ is most often used for &rest arguments.
    (defun user-name+home-phone (user-id)
    "Returns the “real name” and “home phone” for user with ID USER-ID as multiple values.
    Reads the GECOS field. SBCL+Linux-specific, probably."

    (destructuring-bind (real-name office office-phone home-phone &rest _)
    (uiop:split-string (sb-posix:passwd-gecos (sb-posix:getpwuid user-id))
    :separator ",")
    (declare (ignore office office-phone _))
    (values real-name home-phone)))
  • Argument names are usually self-documenting; since most IDE's will show the argument names in some way (eg: Emacs shows them in the mode line after a function name is entered), using a name like message rather than m (for example) will make the usage clearer. Functions with more than 2 arguments will usually have many/most arguments as keyword arguments.
  • Some programmers will use a trailing $ to indicate a stringified representation of an object; eg, (let ((number-of-hamsters$ (princ-to-string number-of-hamsters))) … ) or (let ((number-of-hamsters (parse-integer number-of-hamsters$))) … )
  • Almost no-one will export a function (or variable) whose name conflicts with a name in the Common-Lisp package, since nearly every possible user will be in a package that has (:use :common-lisp …) in its definition.
  • There are also rather strict conventions about indentation, comments, and formatting (inline) documentation which aren't really about naming things.



True to form, Forth is very unconventional when it comes to Naming conventions. The language is based on the concept of a WORD. A WORD in Forth is simply a text name that exists in the Forth dictionary. When a WORD is invoked, it causes some code to run. The code that runs could be anything; a sub-routine, a constant, a named memory address or the "main" routine of the program itself. It is completely free form.

What's more in Forth any ASCII character can be used to name a WORD with the exception of control characters and the space character. This sounds like a path to chaos and if the programmer chooses to use this power it can give new meaning to the phrase "code obfuscation". However the language itself uses specific characters for some specific purposes and these have come to be used by Forth programmers when naming their own WORDs. The freedom in naming also allows Forth programmers to emulate naming conventions from other languages if it is appropriate.

Older Forth systems were case sensitive and all keywords were upper case. Most modern systems allow case sensitivity to be on or off. Some programmers prefer all standard Forth words in the code to be uppercase. As with many aspects of Forth there are divergent opinions on the use of case in code but the language can accommodate them.

Disclaimer: The naming convention examples shown are taken from the experience of the author and are by no means complete.

Fetch and Store[edit]

Forth has a WORD to fetch an integer from a memory address called '@' and another WORD to store an integer to memory called '!'. There are also WORDs to fetch and store double integers called 2@ and 2!. This is the beginning of a common naming convention in Forth. The '@' and '!' characters are used as suffixes for WORDs that get or put data.

\ fetch and store usage examples
\ record example using this convention
1 PERSONEL RECORD@ \ read Record 1 and put pointer on data stack

Colon, Semi-colon[edit]

The Forth compiler is activated with ":" which is just another WORD to Forth. The colon WORD accepts the name of a new word and then begins compiling the WORDs that come after until the WORD ';' is encountered in the input stream. For this reason these two characters are sometimes used in naming WORDS that create new words or for example in Object orient extensions to Forth.

\ buffer is a word that creates a named memory space and ends in a ':'
: buffer: ( bytes -- ) create allot ;
hex 100 buffer: mybuffer \ buffer: creates a new WORD in the dictionary call mybuff
\ if object programming extensions are added to Forth they could look like this
class: myclass <super integer
m: get @ ;m \ create the methods with m: ;m
m: put  ! ;m
m: clear 0 swap ! ;m


From the beginning[edit]

The name of every Fortran variable must start with a letter and continues with letters and digits only. A variable has an implicit type determined by the first letter of the variable's name. The implicit types are as follows:

First Fortran (1957, for the IBM704) provided no type declarations, so all variables had to be named according to the fixed implicit typing rule, further, no name could be the same as that of a library function after its terminating F was removed. Thus, SINF was for the sine function and so SIN was not an available name for a variable. Similarly, fixed-point (i.e. integer) functions had to start with X despite the rule for variables. The DIMENSION statement defined the sizes of arrays but there was no requirement on the form of the name, for instance that the first letter be an A or similar. Typically, loop variables and array indices are one of I, J, K, L, M, N but there is no requirement enforcing this, other than the integer type rule.

Fortran II (1958, for the IBM704) removed the odd linkage between the names of variables and library functions, and introduced the FUNCTION statement for user-written functions. There was still no type declaration scheme, but now the first letter of a function's name defined the type in the same way as with the names of variables.

Later compilers removed the requirement that library function names end with F, introduced type declarations (INTEGER, REAL, DOUBLE PRECISION, COMPLEX, etc.), and allowed additional symbols such as an underline and $. Early Fortran source was written all in capitals, but later compilers allow lower case as being equivalent. With F90, the TYPE statement allowed the declaration of compound data aggregates, with % or . used in the name parts, as in Location.Latitude = -38

Function names[edit]

  • "D" is often used to indicate that an INTRINSIC FUNCTION returns a DOUBLE PRECISION REAL number. e.g. "cosine" in DOUBLE precision is DCOS, and as a suffix that the argument is in degrees rather than radians as in DCOSD - if available.
  • "C" is often used to indicate that an INTRINSIC FUNCTION returns a COMPLEX number. e.g. "cosine" in COMPLEX use CCOS
  • "Q" is often used to indicate that an INTRINSIC FUNCTION returns a QUAD PRECISION REAL number. e.g. "cosine" in QUAD precision is QCOS

And combinations can be applied...

  • "CQ" is often used to indicate that an INTRINSIC FUNCTION returns a QUAD COMPLEX number. e.g. "cosine" in QUAD COMPLEX use CQCOS

A persistent problem[edit]

Rather than evoking an "undeclared" error message any misspelled variables will be implicitly declared. Typographic mistakes may result in syntactically correct but semantically wrong statements involving such undeclared names, especially given that Fortran disregards spaces outside text literals so that GO TO is just as valid as G OTO. Such errors are very difficult to perceive in source listings. For example the output from the following snippet isn't all the integers from 1 to 10:

      DO 999 I=1 10

Notoriously, the U.S.A.'s first Venus satellite probe was lost due to the difference between DO 3 I = 1.3 and DO 3 I = 1,3 Such texts when printed in wobbly glyphs through a coarse ink ribbon onto rough paper by a lineprinter in a hurry are not obviously incorrect...

Quirky response
In Fortran 77 then
was available to disable implicit typing and thus evoke "undeclared variable" messages. Prior to this the code could use
in the hope that the compiler would detect an undeclared LOGICAL variable used in a numerical context, and hence report a semantic type error.


FreeBASIC is not case sensitive and keywords and identifiers can be written in lower case, upper case or mixed case.

Ordinary identifiers can only consist of letters (a-z), numerals (0-9) or the underscore character (_) and cannot begin with a numeral. However, some keywords also include other characters such as #, $ or ?.

Apart from intrinsic 'defines', underscores are not used in the language's keywords even though some of them are multi-word.

There are no official or 'de facto' naming conventions for variables, constants, functions, types etc. and individual developers therefore tend to develop their own style. This may depend on their exposure to other languages such as C, C++, C#, Java or Pascal and the conventions commonly used in those languages.

As long as a consistent style is used, code readability does not seem to be an issue.


Most keywords are in lowercase. Of punctuation marks, only the colon is considered as uppercase and all others that are valid are considered as lowercase.

Haskell requires that names of types, constructors, classes, and modules start with an uppercase letter, while names of constants, variables, fields of record types, must start with lowercase letters.

It is common to use camel case although not required. Sometimes the name of something ends with an apostrophe to represent a mathematical "prime" mark.


The nice thing about conventions is much like the nice thing about standards: there are so many to choose from.

Classic J tends to favor terse names. One influence, here, is that it's rather dismaying when the name of your procedure is longer than its implementation. This matches the style of classic works on mathematics, and also makes it easier to type, and easier to keep code near to related code. This style is especially popular with local variables.

J also sometimes borrows from C's conventions (ALL CAPS constant names, for example).

Another convention describes the transformation being done using the convention afterFromBefore. This matches the right to left style of assignment operations (which much of J's syntax also adopts). When combined with the "terse naming" convention, you get things like hfd (meaning hexadecimal from decimal).

Another convention, when dealing with external code, involves simply using the foreign names. You can see this, for example, in the opengl support. This makes it a bit easier to use the original documentation.

Other conventions are also in use.


Kotlin's published 'Coding Conventions' specify the following styles for naming program entities:

  • use camelCase for names (and avoid underscore)
  • types start with upper case
  • methods and properties start with lower case

In addition to these conventions, it is common practice for enum members and compile time constants to have names which are all upper case and therefore use snake_case to separate words.

Although most of the Kotlin code I have seen follows these conventions, they are not obligatory. Some developers, for instance, like to prefix the private members of a type with an underscore.

The following program illustrates these conventions:

// version 1.0.6
const val SOLAR_DIAMETER = 864938
class Star(val name: String) {
fun showDiameter() {
println("The diameter of the $name is ${"%,d".format(SOLAR_DIAMETER)} miles")
class SolarSystem(val star: Star) {
private val planets = mutableListOf<Planet>() // some people might prefer _planets
init {
for (planet in Planet.values()) planets.add(planet)
fun listPlanets() {
fun main(args: Array<String>) {
val sun = Star("sun")
val ss = SolarSystem(sun)
println("\nIts planetary system comprises : ")
The diameter of the sun is 864,938 miles

Its planetary system comprises :

OASYS Assembler[edit]

Prefixes and suffixes are required on names. It is allowed for a name to consist of only the prefix and/or suffix without any letters or numbers.

The prefix is one of:

  • no prefix = Built-in opcode or a macro
  • ! = Static object
  • % = Global variable
  • , = Local variable or argument
  • . = Property
  • & = Method
  • ? or * = Class
  • : = Label
  • ' = Vocabulary word

The suffix specifies the data type of a variable or property or argument or the type of the return value of a method, and it is one of:

  • no suffix = Void; used for methods which do not return a value
  • @ = Object
  • # = Integer
  • $ = String
  • ^ = Pointer; may be followed by another suffix

Terse names are generally preferred.


Almost everything can be a word so almost every convention can be used.

Oforth language built-ins use thoses conventions : - Global constants name are uppercase. Example : JUSTIFY_LEFT

- Constants for a class are prefixed by the class name. Example : Date.JANUARY, Date.Months

- Classes and properties begin with an uppercase letter. Examples: Object, Integer, Comparable.

- Methods begin with a lowercase letter. Examples: first, max, and, ....

- Functions or methods that require reading another word end with ':'. Examples: loop: , for: , new: , ...

Perl 6[edit]

Perl 6 is written in Unicode, and has consistent Unicode semantics regardless of the underlying text representations. By default Perl 6 presents Unicode in "NFG" formation, where each grapheme counts as one character. A grapheme is what the user would think of as a character in their normal everyday life, including any diacritics.

Built-in object types start with an uppercase letter. This includes immutable types (e.g. Int, Num, Complex, Rat, Str, Bit, Regex, Set, Block, Iterator), as well as mutable (container) types, such as Scalar, Array, Hash, Buf, Routine, Module, and non-instantiable Roles such as Callable and Integral. The names may extend to CamelCase for compound words: IntStr, CaptureCursor, BagHash, SoftRoutine.

Non-object (native) types are lowercase: int, num, complex, rat, buf, bit.

Nearly all built-in subroutines, functions, methods and pragmas included in Perl 6 CORE are lowercase or lower kebab-case. (Compound words joined with hyphens rather than underscores or camelCase.) .grep, .pairs, .log, .defined, .subst-rw. The few notable exceptions are those which can radically change behaviour of the executing code. They are in all-cap/kebab-case to make them stand out: EVAL, MONKEY-TYPING.

All upper case names are semi-reserved. You are free to use them, but are warned that you may encounter future collisions with internal usage. Upper case names are used for pseudo-packages: MY, OUR, CORE, GLOBAL, etc., for relative scope identifiers: CALLER, OUTER, SETTING, PARENT, etc. and other things.

Variables in Perl 6 CORE tend be lower kebab-case for lexical variables and upper case for special or package globals. They have an attached, prefix sigil (or twigil) to indicate what type of object they hold and what methods are available to operate on them.

In user space, there are very few restrictions on how things are named. Identifers of any type can not contain white space. Subroutines must start with a letter character, any unicode character that has a "letter" property. Variable names can't contain any of the sigil, twigil or comment characters ($, @, %, *, ?, =, :, #). Outside of those few restrictions, it's pretty much a free-for-all.

That being said, there are some community conventions which are encouraged, though not enforced. Descriptivness is favoured over terseness, though this should be scaled to the scope of the object. It is perfectly fine to name an index variable in a three line loop, $i. An object in global scope with dozens of methods may be better off with a more descriptive name. It is encouraged to name subroutines for what they do to make it easier for others to follow your logic. Nouny things should have nouny names. Verby things should be verby. If you aren't going to follow convention, at least be consistent.


Conventions are not strictly enforced.
Builtin and library routines are full english lowercase words and underscore separated, eg custom_sort()
Function-style invocation is common instead of infix operators for less-used and new features, eg power(3,5)
Constants are often uppercase, eg PI
Keywords are always lowercase, eg while
The end keyword always has an explicit match, eg end while

Variable names are case-sensitive and may not contain any embedded operators or spaces
Over-loading or over-riding the names of variables and routines is generally frowned upon
Some unicode characters are permitted, in an ad-hoc manner via fairly trivial mods to ptok.e
The pGUI.e library retains the original IUP C names, eg IupDialog

File extensions generally imply the following:
.e - general purpose include, not executable standalone
.ew - windows-only include
.eu - linux-only include
.exw - historically this implied windows-only, but is now also used for any cross-platform gui applications.


PicoLisp has not hard-coded naming rules, with the exception of symbols starting with an at-mark '@': They have special meaning as "pattern variables" for the 'match' and 'fill' functions, and as 'Pilog' variables.

Besides this, PicoLisp programs follow these naming conventions:

- Global variables start with an asterisk '*'
- Global constants may be written all-uppercase
- Functions and other global symbols start with a lower case letter
- Locally bound symbols start with an upper case letter
- Local functions start with an underscore '_'
- Classes start with a plus-sign '+', where the first letter
   - is in lower case for abstract classes
   - and in upper case for normal classes
- Methods end with a right arrow '>'
- Class variables may be indicated by an upper case letter


Microsoft describes a cmdlet as a lightweight command that is used in the Windows PowerShell environment. The Windows PowerShell runtime invokes these cmdlets within the context of automation scripts that are provided at the command line. The Windows PowerShell runtime also invokes them programmatically through Windows PowerShell APIs. The built-in cmdlets invariably follow the convention of a Verb-Noun pair, e.g.: Get-Process or Set-Content. Cmdlets are Pascal cased with a dash separating the Verb-Noun pair.

Functions are user-defined (script-based) equivalents to the built-in cmdlets; therefore, any function (that is not a simple "helper" function) should probably follow the naming convention of cmdlets. I have experimented with function naming and found that a function could be named something as silly as Out-%k+^, but why would one want to do that? Users may define modules containing functions and variables which is very handy, but a function defined in a module must follow the cmdlet naming convention or a warning will appear on the screen when the module is loaded.

Aliases may be defined for any cmdlet or function, so name your function with a meaningful (and conventional) name, then define an alias for it. There are many built-in aliases and they are all based on shortened PowerShell names, Unix or MS-DOS, e.g.: Get-Content = gc = cat = type.

Variables are prefixed with a "$" as in Perl and as such, should probably be camel cased. A variable must be alphanumeric (in any order) and may contain underscore characters. PowerShell, of course, offers the option of naming a variable "anything" if the user surrounds the name with ${}, e.g.: ${one two three} = @(1, 2, 3).


  • Class names are typically in CamelCase, often this is reflected in the module name.
  • Private member functions are embeded between "__" to make a member function "private".
  • Variables are generally lower-case.


For more details, read the explanation in the Name section of the Style Guide: .

The convention is to use full English lowercase words separated by dashes

#lang racket 

Usually _ is used only as the name of a dummy argument.

Most functions names have as prefix the data type of the main argument. Some notable exceptions are the functions for lists and boxes, for backward compatibility.

#lang racket 
(string-ref "1234" 2)
(string-length "123")
(string-append "12" "34")
(append (list 1 2) (list 3 4))
(unbox (box 7))

This convention generalizes the selector-style naming scheme of structs.

#lang racket
(struct pair (x y) #:transparent #:mutable)
(define p (pair 1 2))
(pair-x p)  ; ==> 1
(set-pair-y! p 3)
p  ; ==> (pair 1 3)

The name of conversion procedure is usually like from->to

#lang racket
(list->vector '(1 2 3 4))
(number->string 7)

In addition to regular alphanumeric characters, some special characters are used by convention to indicate something about the name. The more usual are:

;predicates and boolean-valued functions:  ?
(boolean? 5)
(list? "123")
;setters and field mutators:  !
(set! x 5)
(vector-set! v 2 "x")
; classes:  %
;interfaces: <%>;


implicit types[edit]

The (Classic) REXX language has no implicit types for variable (names) or function (names)   except
that   all   variables'   values   are of the type   character.

So, it can be thought that the implicit type for   everything   is the type   character.


All numbers are stored as characters:   decimal digits, with/without signs, decimal points, and exponents
(and blanks where permitted).

Values that conform to the REXX definition of a number (below) are treated as a number:

{blanks}  {-│+}  {blanks}  {digits}  {.}  {digits}  {e│E}  {-│+}  {exponent}  {blanks}

(Decimal)   digits   are any of the digits:   0 1 2 3 4 5 6 7 8 9.

The   e   or   E   (above) signifies the following decimal number is an exponent   (a power of ten that
is implicitly multiplied to the preceding number).

Everything (for a number) is optional,   but there must be   at least   one decimal digit.

If an   e   or   E   is present, it must be immediately followed by an integer   (a decimal exponent),
with/without an optional sign.

A leading sign   (for a number)   if present, may have a minus sign ()   or   a plus sign (+).

variable names[edit]

Naming conventions (as far as capitalization is concerned) is that variable names may be in any case,
the REXX language definition is that variable names are stored in capital letters internally.

Another restriction is that the variable name can't start with a decimal digit.

In Classic REXX, characters other than the Latin (English) alphabet that can be used such as:

  •    !     (explanation point)
  •   _     (underscore or underbar)
  •   $     (dollar sign)
  •    ?     (question mark)
  •   #     (pound sign or hash)
  •   @     (commercial at sign)

Some Classic REXX interpreters allow additional characters   [such as the   ¢   (cent sign)].

Other characters are also allowed   after   the first character (above):

  •   .     (a period or decimal point)
  •   the decimal digits   0   through   9

So:     AbcXyz,   abcxyz,   ABCxyz   all refer to the same variable.

function names[edit]

Naming conventions for the REXX BIFs   (built-in functions)   are all in uppercase, but they can be
coded in lowercase (or mixed case) for ease-of-use and readability.

For example:


─── where   length   is a REXX BIF for the   length   of the   value   of the variable   ABC

If there is an internal function with a built-in function's name in the program,   the built-in (REXX)
function can be invoked using its name as an uppercase literal string as shown below:

s= 'abcd'
say "length(s) =" length(s) /* ──► 1000 */
say "'LENGTH'(s) =" 'LENGTH'(s) /* ──► 4 */
length: return 1000
length(s) = 1000
'LENGTH'(s) = 4

label names[edit]

Labels in Classic REXX can be any of the Latin (English) alphabet, as well as the decimal digits   0 ──► 9,
in addition to other characters such as:

  •   .     (a period or decimal point)
  •    !     (explanation point)
  •   _     (underscore or underbar)
  •   $     (dollar sign)
  •    ?     (question mark)
  •   #     (pound sign or hash)
  •   @     (commercial at sign)

Label names may start with any of the above characters.

Some Classic REXX interpreters allow additional characters   [such as the   ¢   (cent sign)].

Note that REXX keeps the label names as capitalized letters, but either lowercase/mixed/upper
case may be used interchangeably.


The naming conventions in Ruby are almost on the whole agreed upon by the Ruby community. Ruby is a case sensitive language which means that HelloWorld is different from helloworld.

Variable Names[edit]

In ruby, all variables must begin with a lower case letter or an underscore. Variables rarely begin with underscores and variable names should be relatively descriptive in ruby. Additionally, ruby uses snake case for variable names. This means that if I wanted to have a variable that held the time of day, I'd call that variable time_of_day. Instance variables begin with @, class variables begin with @@ and global variables begin with $


In ruby, constants must being with an upper case letter and are traditionally in screaming snake case (note: this is the one point of contention within the ruby community when it comes to naming conventions. A majority of ruby users use screaming snake case, but some use Pascal Case for constant names instead). Anything assignable object that begins with an uppercase letter is automatically a constant in ruby. Constant names should be descriptive as well. For example, a constant for the recursion limit could be RECURSION_LIMIT.

Method names[edit]

Method names in ruby are quite similar to variable naming conventions with a few additional rules. In ruby, a method that returns a boolean traditionally ends with a question mark. Many of these methods exist in the standard library such as, 1.positive? or 'test'.tainted?. Also, so called destructive methods end with an exclamation point. For example,

test_variable = [1, 9, 8, 3]
test_variable.sort # => [1, 3, 8, 9]
test_variable # => [1, 9, 8, 3]
test_variable.sort! # => [1, 3, 8, 9]
test_variable # => [1, 3, 8, 9]

The sort method just returns a sorted version of the array, but the sort! method sorts the array in place. Additionally, Ruby has accessors in its class so you don't need to write explicit getters or setters, but if you do the proper naming convention for a getter is field_name and the proper naming convention for a setter is field_name=. An example of this will be seen later on in this description. Constructors are always named initialize.

Classes and Modules[edit]

Classes and modules have the same naming convention in ruby. They should be in Pascal case and they should be descriptive.

Putting it all together[edit]

Here is an example of a ruby file with proper naming conventions being used.

# Global variable
$number_of_continents = 7
module Banking
# Module constants for semantic versioning
class BankAccount
attr_accessor :first_name, :last_name
attr_reader :account_number
@@ATM_FEE = 3.75
@@adiministrator_password = 'secret'
# The class's constructor
def initialize(first_name, last_name, account_number)
@first_name = first_name
@last_name = last_name
@account_number = account_number
@balance = 0
# Explicit setter as extra behavior is required
def account_number=(account_number)
puts 'Enter administrator override'
if gets == @@adiministrator_password
@account_number = account_number
puts 'Sorry. Incorrect password. Account number not changed'
# Explicit getter as extra behavior is required
def balance
"$#{@balance / 100}.#{@balance % 100}"
# Check if account has sufficient funds to complete transaction
def sufficient_funds? (withdrawal_amount)
withdrawal_amount <= @balance
# Destructive method
def donate_all_money!
@balance = 0


Tcl leaves nearly all matters of variable and procedure naming up to the programmer, so styles vary. Variables are not declared by type. However, each variable contains a scalar, list, or hash array. Once assigned a scalar, list, or array, a variable must be unset to be re-assigned a different kind (scalar, list or array).

A few conventions are common:

  • Names typically use alphanumeric characters (a-zA-Z0-9_). Use of other characters are allowed, but may require extra quoting with curly braces ({}) (See ref: Rule #7)
  • Two naming styles dominate for variables: all_lower_case_with_words_separated_by_underscore or camelCase
  • Namespaces are usually named in lowercase, starting with a letter ({[a-z][a-z0-9_]*}) and separated by double colons (::). For example space1::space2::space3
  • TitleCase names are typically used for private members. TclOO's default export pattern {[a-z]*} supports this convention.
  • options/flags are typically spelled in all lowercase with no internal punctuation: -nonewline for example.
  • Internalized commands and variables may begin a leading underscore _ to differentiate them from externalized API.
  • The variable value unknown is special in some contexts: it can be used to handle the "no such method" or "no such command" case.
  • Specific array names _ and {} (the empty string) are used quite commonly for internal state
  • Procedure parameter args is used for variadic functions, and typically this name is never used for anything else
  • Tk graphics toolkit window names start with . and must not have a capital letter in the next position
  • Combinations of nonstandard characters may be used to create variables that are hidden ie not printable. These are still discoverable without much effort. Hiding variables is not a recommended security strategy.

Sometimes suffixes are added to variables to indicate a significant way that they are used. Here's some examples. These are not standardized by any means:

  • example_p The suffix _p implies Boolean value ie true/false represented as 1 or 0.
  • example_list Implies the variable contains a list of values.
  • example_arr() The suffix _arr implies variable is an array of scalar values.
  • example_larr() The suffix _larr implies the variable is an array of list values.
  • example_ts The suffix _ts implies its value is a timestamp
  • example_s The suffix _s implies its value is in seconds or seconds from epoch.
  • example_i The suffix _i implies its value is an integer.

Visual Basic[edit]

Microsoft was encouraging camelCase in Visual Basic. And at the beginning Microsoft was also encouraging programmers to use Hungarian notation.
Camel case:
The variable name begins with a prefix and has one or more uppercase inside.

Dim dblDistance as Double

Hungarian notation:

Dim iRow as Integer, iColumn as Integer
Dim sName as String
Dim nPopulation as Long
Dim xLightYear as Double
iRow = iRow + 1

Prefix i is for index and n for count. The Hungarian notation reminds in a way FORTRAN implicit type: prefix characters i,j,k,l,m,n for integers and the rest for reals.
The real advantage is for the names of the VB controls.

Prefix Meaning
frm Form
mnu Menu
cmd Command button
chk Check button
opt Radio button
lbl Text label
txt Text edit box
pic Picture
cbo Combo box
tmr Timer
... ...


txtTraduc.Width = iWidth
cmdSolution.Enabled = False
mnuAleatoire.Checked = False
frmScore.Show vbModal
picFace.Visible = False
picFace.Picture = LoadPicture(sFileName)

The advantage comes clear for the “Private Sub” names of the controls:



  • Conventions are for the user to [create and] follow, no enforcement.
  • The compiler uses the "__" prefix as its "name space". For example: __DATE__, __sGet. A program can also use that format.
  • The compiler will put a "#" (comment in source code) in a name to mark it as "out of bounds". For example "__fcn#1_2" is the first lambda function and is located at source line 2.
  • Names must be unique. For example, a variable can not have the same name as a function. This is a confusion reducer.
  • Names are restricted to 80 characters of [A-Za-z0-9_], plus "#" when bypassing the tokenizer.