Naming conventions: Difference between revisions

From Rosetta Code
Content added Content deleted
(Added FreeBASIC)
Line 361: Line 361:
In Fortran 77 then <lang fortran>IMPLICIT NONE</lang> was available to disable implicit typing and thus evoke "undeclared variable" messages. Prior to this the code could use
In Fortran 77 then <lang fortran>IMPLICIT NONE</lang> was available to disable implicit typing and thus evoke "undeclared variable" messages. Prior to this the code could use
<lang fortran>IMPLICIT LOGICAL</lang> in the hope that the compiler would detect an undeclared LOGICAL variable used in a numerical context, and hence report a semantic type error.
<lang fortran>IMPLICIT LOGICAL</lang> in the hope that the compiler would detect an undeclared LOGICAL variable used in a numerical context, and hence report a semantic type error.

=={{header|FreeBASIC}}==
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.


=={{header|Haskell}}==
=={{header|Haskell}}==

Revision as of 21:07, 31 October 2016

Task
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



ALGOL 68

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. <lang algol68>MODE ℵ SIMPLEOUT = UNION (≮ℒ INT≯, ≮ℒ REAL≯, ≮ℒ COMPL≯, BOOL, ≮ℒ BITS≯, CHAR, [ ] CHAR); PROC ℓ cos = (ℒ 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' ¢;

PROC ℓ arccos = (ℒ REAL x) ℒ REAL: ¢ if ABS x ≤ ℒ 1, a ℒ real value close

     to the inverse cosine of 'x', ℒ 0 ≤ ℒ arccos (x) ≤ ℒ pi ¢; </lang>

For LONG LONG MODEs this would be coded as: <lang algol68>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 ¢; </lang>

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
do
  sum sq+:=i↑2
od
Quote stropping
(like wikitext)

<lang algol68> 'pr' quote 'pr' 'mode' 'xint' = 'int'; 'xint' sum sq:=0; 'for' i 'while'

 sum sq≠70×70

'do'

 sum sq+:=i↑2

'od' </lang>

For a 7-bit character code compiler

<lang algol68> .PR UPPER .PR MODE XINT = INT; XINT sum sq:=0; FOR i WHILE

 sum sq/=70*70

DO

 sum sq+:=i**2

OD </lang>

For a 6-bit character code compiler

<lang algol68> .PR POINT .PR .MODE .XINT = .INT; .XINT SUM SQ:=0; .FOR I .WHILE

 SUM SQ .NE 70*70

.DO

 SUM SQ .PLUSAB I .UP 2

.OD </lang>

Algol68 using res stropping
(reserved word)

<lang algol68> .PR RES .PR mode .xint = int; .xint sum sq:=0; for i while

 sum sq≠70×70

do

 sum sq+:=i↑2

od </lang>

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

AntLang

<lang AntLang>variables-are-often-lower-case-and-seperated-like-this-one</lang>

AWK

<lang AWK>

  1. Field names begin with $ so $1 is the first field, $2 the second and $NF the
  2. last. $0 references the entire input record.
  3. Function and variable names are case sensitive and begin with an alphabetic
  4. character or underscore followed by any number of: a-z, A-Z, 0-9, _
  5. The awk language is type less; variables are either string or number
  6. depending upon usage. Variables can be coerced to string by concatenating ""
  7. or to number by adding zero. For example:
  8. str = x ""
  9. num = x + 0
  10. Below are the names of the built-in functions, built-in variables and other
  11. reserved words in the awk language separated into categories. Also shown are
  12. the names of gawk's enhancements.
  13. patterns:
  14. BEGIN END
  15. BEGINFILE ENDFILE (gawk)
  16. actions:
  17. break continue delete do else exit for if in next return while
  18. case default switch (gawk)
  19. arithmetic functions:
  20. atan2 cos exp int log rand sin sqrt srand
  21. bit manipulation functions:
  22. and compl lshift or rshift xor (gawk)
  23. i18n functions:
  24. bindtextdomain dcgettext dcngettext (gawk)
  25. string functions:
  26. gsub index length match split sprintf sub substr tolower toupper
  27. asort asorti gensub patsplit strtonum (gawk)
  28. time functions:
  29. mktime strftime systime (gawk)
  30. miscellaneous functions:
  31. isarray (gawk)
  32. variables:
  33. ARGC ARGV CONVFMT ENVIRON FILENAME FNR FS NF NR OFMT OFS ORS RLENGTH RS RSTART SUBSEP
  34. ARGIND BINMODE ERRNO FIELDWIDTHS FPAT FUNCTAB IGNORECASE LINT PREC PROCINFO ROUNDMODE RT SYMTAB TEXTDOMAIN (gawk)
  35. function definition:
  36. func function
  37. input-output:
  38. close fflush getline nextfile print printf system
  39. pre-processor directives:
  40. @include @load (gawk)
  41. special files:
  42. /dev/stdin /dev/stdout /dev/error

</lang>

BASIC

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

BBC BASIC

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: <lang bbcbasic>DEF PROC_foo(bar, baz$(), quux%, RETURN fred%, RETURN jim%)</lang> 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".

C

Base language
  • All reserved words and operators are lower-case. e.g. while, for, if, sizeof and return etc.
Libraries

Constants that appear in C "header" files are typically in upper-case: <lang c>O_RDONLY, O_WRONLY, or O_RDWR. O_CREAT, O_EXCL, O_NOCTTY, and O_TRUNC</lang> 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 "__": <lang c>extern size_t fwrite (__const void *__restrict __ptr, size_t __size,

                     size_t __n, FILE *__restrict __s) __wur;</lang>

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. <lang c>#include <math.h> double cos(double x); float cosf(float x); long double cosl(long double x);</lang>

Whereas for complex variable a prefix of "c" is added. <lang c>#include <complex.h> double complex ccos(double complex z); float complex ccosf(float complex z); long double complex ccosl(long double complex z);</lang>

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: <lang c>#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, ...);

  1. 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);</lang>

Quirks

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

Forth

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

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. <lang>\ fetch and store usage examples VARIABLE MYINT1 VARIABLE MYINT2 2VARIABLE DOUBLE1 2VARIABLE DOUBLE2

MYINT1 @ MYINT2 ! MYDOUBLE 2@ MYDOUBLE 2!

\ record example using this convention

1000000 RECORDS PERSONEL

1 PERSONEL RECORD@ \ read Record 1 and put pointer on data stack

HR_RECORD 992 PERSONEL RECORD! \ store HR_RECORD </lang>

Colon, Semi-colon

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. <lang>\ 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
class

</lang>

Fortran

From the beginning

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:<lang fortran>IMPLICIT REAL(A-H,O-Z), INTEGER(I-M)</lang> 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

  • "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

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: <lang fortran> DO 999 I=1 10

       PRINT *,I

999 CONTINUE</lang>

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 <lang fortran>IMPLICIT NONE</lang> was available to disable implicit typing and thus evoke "undeclared variable" messages. Prior to this the code could use <lang fortran>IMPLICIT LOGICAL</lang> 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

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.

Haskell

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.

J

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.

OASYS Assembler

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.

Oforth

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

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.

PicoLisp

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

PowerShell

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).

Python

  • 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.

Racket

For more details, read the explanation in the Name section of the Style Guide: http://docs.racket-lang.org/style/Textual_Matters.html#%28part._names%29 .

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

<lang Racket>#lang racket render-game-state send-message-to-client traverse-forest</lang>

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>#lang racket (string-ref "1234" 2) (string-length "123") (string-append "12" "34")

exceptions

(append (list 1 2) (list 3 4)) (unbox (box 7))</lang>

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

<lang Racket>#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) </lang>

The name of conversion procedure is usually like from->to <lang Racket>#lang racket (list->vector '(1 2 3 4)) (number->string 7)</lang>

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

<lang Racket>

predicates and boolean-valued functions
?

(boolean? 5) (list? "123")

setters and field mutators
!

(set! x 5) (vector-set! v 2 "x")

classes
%

game-state% button-snip%

interfaces
<%>;

dc<%>; font-name-directory<%></lang>


REXX

implicit types

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.

numbers

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} {sign} {blanks} {digits} {.} {digits} {e|E} {sign} {exponent} {blanks}

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

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

If an   e   or   E   is present, there must immediately be an integer decimal exponent following.

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

variable names

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

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: <lang rexx>w=length(abc)</lang> ─── where   length   is a REXX BIF for the   length   of the   value   of the variable   ABC

If there is an internal function with a builtin function's name in the program, one can invoke the builtin function using its name as an upercase literal string as shown here: <lang rexx>s='abcd' say "length(s)="length(s) /* -> 1000 */ say "'LENGTH'(s)="'LENGTH'(s) /* -> 4 */ Exit length: Return 1000</lang>

Output:
length(s)=1000
'LENGTH'(s)=4

label names

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.

Tcl

This example is in need of improvement:

A concise example or two would do wonders here. Perhaps some of the existing challenge pages can be linked?

Tcl leaves nearly all matters of naming up to the programmer, so styles vary a bit. A few conventions are common:

  • variable names typically only use a-zA-Z0-9_ as these can be used without {} (Rule #7)
  • command names are typically lower_case or camelCase
  • namespaces are usually named in lowercase, starting with a letter ({[a-z][a-z0-9_]*}).
  • 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 lower case with no internal punctuation: -nonewline
  • Tk window names start with . and must not have a capital letter in the next position
  • by convention, it's common to name hidden commands (eg: those that have been renamed and wrapped) with a leading underscore _
  • the name unknown is special in some contexts: it can be used to handle the "no such method" or "no such command" case
  • the array names _ and {} (the empty string) are used quite commonly for private state
  • the variable args is used for variadic functions, and typically this name is never used for anything else

zkl

  • 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.