Naming conventions: Difference between revisions
m
Reformatting text which was overflowing the page width.
(→Function names: Confusion over letters?) |
m (Reformatting text which was overflowing the page width.) |
||
| (89 intermediate revisions by 38 users not shown) | |||
Line 1:
{{task|Programming environment operations}} [[Category:Simple]]
Many languages have naming conventions regarding the identifiers used in the language, its libraries, and programs written in the language. Such conventions, which may be classified as ''de facto'' or ''de jure'' depending on how they are enforced,
The naming conventions are sometimes a bit haphazard, especially if the language and/or library has gone through periods of evolution. (In this case: give a brief example and description.)
Document (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)
Line 15 ⟶ 16:
Any cases where the naming convention as commonly violated.
If possible, indicate where the convention
;See also:
* Wikipedia: [[wp:Naming convention (programming)|Naming convention (programming)]]
<br><br>
=={{header|11l}}==
* Type names are typically in CamelCase.
* Functions, variables, and module names are lower-case.
=={{header|360 Assembly}}==
<!-- Naming conventions -->
No real naming conventions for S/360 Assembler except the strict rule for names (called symbols).<br>
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.
=={{header|6502 Assembly}}==
* Opcodes can be upper or lower case, or any combination thereof. However the letters must be correct.
* Labels cannot start with a number. They usually use CamelCase with the first letter lowercase.
* Constants are typically in all capitals.
* Variables are typically in lower case.
* A subroutine called by a macro will often be the macro's name with "do" in front. For example, if a macro is named "getScreenPosition" the associated subroutine is called "doGetScreenPosition" (note that the G in Get is now capitalized since it's no longer the beginning of the name.)
* <code>byte</code> is 8-bit and <code>word</code> is 16-bit. Strings, pointers, and other data still use either of these declarations depending on what is appropriate. It is up to the program to interpret this data "correctly" - the CPU does not enforce data types whatsoever.
=={{header|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.
<
PROC ℓ cos = (ℒ REAL x) ℒ REAL: ¢ a ℒ real value close to the cosine of 'x' ¢;
Line 31 ⟶ 55:
PROC ℓ arccos = (ℒ 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 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 '''proc'''edure is generally prefixed to the '''proc'''edure name.
Line 60 ⟶ 84:
'''od'''
|| Quote stropping<br/>(like [[wp:Lightweight markup language#Text/font-face formatting|wikitext]])
<
'pr' quote 'pr'
'mode' 'xint' = 'int';
Line 69 ⟶ 93:
sum sq+:=i↑2
'od'
</syntaxhighlight>
|| For a [[wp:List of binary codes#Seven-bit binary codes|7-bit]] character code compiler
<
.PR UPPER .PR
MODE XINT = INT;
Line 80 ⟶ 104:
sum sq+:=i**2
OD
</syntaxhighlight>
|| For a [[wp:Six-bit character code|6-bit]] character code compiler
<
.PR POINT .PR
.MODE .XINT = .INT;
Line 91 ⟶ 115:
SUM SQ .PLUSAB I .UP 2
.OD
</syntaxhighlight>
|| Algol68 using '''res''' stropping<br/>(reserved word)
<
.PR RES .PR
mode .xint = int;
Line 102 ⟶ 126:
sum sq+:=i↑2
od
</syntaxhighlight>
|}
Note that spaces are permitted in constants, variable and '''proc'''edure names.
Line 174 ⟶ 198:
*tab char
|}
=={{header|AntLang}}==
<
=={{header|Arturo}}==
There are no strict rules for naming new words in Arturo, apart from the ones generally defined in the grammar. That is: ''any letter lowercase-or-upcase, optionally followed by a question mark''.
In practice, a couple of simple naming conventions are followed:
* for function names or variable names, all-lowercase is preferred, e.g <code>variable</code>
* names composed by more than one words, we'd use '''camelCase''', e.g. <code>myVariable</code>
* user constants could be written with a capital first letter and '''PascalCase''', e.g. <code>MainData</code>
* functions returning a boolean value (in Arturo: "predicates") are suffixed with a question mark (<code>?</code>), e.g. <code>prime?</code>
=={{header|AWK}}==
<syntaxhighlight lang="awk">
# Field names begin with $ so $1 is the first field, $2 the second and $NF the
# last. $0 references the entire input record.
Line 225 ⟶ 261:
# special files:
# /dev/stdin /dev/stdout /dev/error
</syntaxhighlight>
=={{header|BASIC}}==
Line 238 ⟶ 274:
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 <tt>FN</tt> or <tt>PROC</tt>, 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:
<
Names like <tt>PROCfoo</tt> and <tt>FNbar</tt> are sometimes used, and even <tt>PROCFOO</tt> and <tt>FNBAR</tt> are entirely legal; but they are probably less readable.
Line 246 ⟶ 282:
If the first line of the program is a comment line of the form <tt>REM >myprog</tt>, the <tt>SAVE</tt> command can be used with no filename and the program will be saved as (in this case) <tt>myprog</tt>. Otherwise, it would be necessary to use <tt>SAVE "myprog"</tt>.
=={{header|BQN}}==
BQN uses a context-free grammar, a result of which it has explicit naming conventions defined in its interpreter. The basic types of values can be distinguished by their first and last characters as follows:
<syntaxhighlight lang="bqn"># Subjects (arrays, numbers, characters, etc) start with a lowercase letter:
var←3
arr←⟨1,2⟩
# Functions start with an uppercase letter:
Fun←{𝕨+𝕩}
Avg←+´÷≠
# 1-modifiers start with an underscore and do not end with an underscore:
_mod←{𝔽𝕩}
# 2-modifiers must start and end with an underscore:
_mod2_←{𝔾𝕨𝔽𝕩}</syntaxhighlight>
=={{header|C}}==
Line 252 ⟶ 301:
;Libraries
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 "__":
<
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.
<
double cos(double x);
float cosf(float x);
long double cosl(long double x);</
Whereas for complex variable a prefix of "c" is added.
<
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:
<
int printf(const char *format, ...);
Line 285 ⟶ 334:
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);</
;Function names
Originally names of C function names were short and in lower case, such as <code>qsort</code> or <code>strcpy</code>. Longer names, perhaps originating from user code or 3<sup>rd</sup> party libraries would be spelled with snake_case, for example, <code>btree_insert</code>
As CamelCase became popular with the introduction of object-oriented style (namely C++ adopting CamelCase from Smalltalk) CamelCase made its way into C, and became somewhat normalized with the introduction of the Windows API, e.g. <code>MessageBox</code> and <code>LoadLibrary</code>. It's now just as likely that user code may opt to use CamelCase, such as, for example, <code>BTreeInsert</code>.
;Quirks
The Unix C standard library uses a prefix of "_" to "hide" raw Operating System calls from the non systems-programmer
=={{header|C sharp}}==
'''Capitalization'''<br/>
- All keywords are lowercase (mandatory)<br/>
- Names of parameters and (private) fields should be camelCase.<br/>
- Names of anything else should be PascalCase.
Possible exception are methods that are automatically generated by a tool.<br/>
For example, the Visual Studio Gui designer will generate names of event handlers based on the variable name: submitButton_Clicked
'''Naming'''<br/>
- Names of enums should be plural if it's a flags enum, otherwise it should be singular.
<syntaxhighlight lang="csharp">public enum Planet {
Mercury, Venus, Earth, Mars, Jupiter, Saturn, Uranus, Neptune
}
[Flags]
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
}</syntaxhighlight>
You should:<br/>
- prefix interface names with I e.g. IPrinter
- prefix generic type parameters with T e.g. <syntaxhighlight lang="csharp">Dictionary<TKey, TValue></syntaxhighlight>
most of the time, a single T is sufficient e.g. <syntaxhighlight lang="csharp">IPrinter<T></syntaxhighlight>
- postfix type names that inherit from EventArgs, Exception, Attribute and EventHandler e.g. MouseMoveEventArgs<br/>
- postfix async method names with Async e.g. GetDataAsync()
You should NOT use:<br/>
- underscores, hyphens or any other nonalphanumeric characters<br/>
- hungarian notation
=={{header|Clojure}}==
* [https://github.com/bbatsov/clojure-style-guide The Clojure Style Guide]
=={{header|Common Lisp}}==
* 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 <code>LIST</code> 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 <code>a…z 0…9 - / + = < > . ! $ % & ? * ~</code> — although only <code>a-z 0-9 -</code> 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: <code>list</code>, <code>List</code>, and <code>LIST</code> (or <code>liST</code>, etc) are identical, but <code>|list|</code> and <code>|LIST|</code> are different from one another. In most environments, <code>list</code> and <code>List</code> are interned the name as <code>|LIST|</code> — ie, the name of the Symbol object is <code>"LIST"</code>. (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 “<code>make-</code>thing,” eg, the standard library function <code>Make-Array</code>.
* Functions that have a side-effect are usually named in a “verb-phrase” form; eg, <code>Format</code> or <code>Delete-File</code>
* 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: <code>SetF</code> itself, <code>IncF</code>, etc.
* Reader (Accessor) functions that return an attribute of an object are usually a noun-like phrase; eg, the function “<code>Symbol-Name</code>” takes a symbol object and returns its name as a string: <code>(Symbol-Name 'List) ⇒ "LIST"</code> 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 <code>Character</code> (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 <code>GetHash</code> due to historical reasons, accessors generally do <i>not</i> have a “Get-” prefix.
** The SetF-accessors for altering a place are usually named identically to the reader functions; eg, a reader function named <code>Person-Surname</code> would be matched to a writer function named <code>(SetF Person-Surname)</code>. This is what is created automatically when using the <code>DefClass</code> macro's <code>:Accessor</code> option on object slots, or when defining slots in <code>DefStruct</code>.
** 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, <code>Wild-Pathname-P</code> 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, <code>StringP</code>. Predicate functions usually do <i>not</i> have a “is-” prefix, like they might in a language like Java.
* Comparator functions for number objects are <code>< <= = >= > /= </code> — for other types, one would usually prefix the operator symbols with the name of the type; eg, <code>Char= String< Timestamp/=</code>. Note that equality is usually <code>=</code> (not <code>==</code>) and not-equal is written <code>/=</code>.
* Functions or variable names with “<code>%</code>” 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 <code>%</code>-name.
* Global/dynamic variables are named with “earmuffs,” ie, leading and trailing asterisks — eg, <code>*Standard-Output*</code>, <code>*Query-IO*</code>. Failure to do so will elicit compiler warnings in some compilers.
* Constants are usually defined with leading and trailing + signs — eg <code>+Some-Constant+</code> — a convention that was <i>not</i> followed in the <code>Common-Lisp</code> package itself (eg: <code>MOST-POSITIVE-FIXNUM</code>)
* Macros that define a new type of thing are usually named <code>Define-</code>some-thing; if the name of the thing being defined is a single, non-hyphenated word, they may be just <code>Def</code>Thing. eg: <code>DefClass</code>, <code>Define-Condition</code>, or <code>Define-SetF-Expander</code>. 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 <code>Assert</code> or <code>Check-Type</code> macros usually are named <code>Assert-</code>some-condition or <code>Check-</code>some-condition. In Emacs, these patterns will highlight the function name, as well. Likewise, functions that signal warnings may be named <code>Warn-</code>whatever.
* Type names for errors or warnings usually explicitly have the word “warning” or “error” in the name, eg, <code>Server-Unreachable-Error</code>
* Macros that establish a dynamic state and clean up after it are usually named <code>With-</code>some-context; eg, <code>With-Open-File</code>, <code>With-Database-Connection</code>. Usually, such a macro will take a first argument as a list like a normal function call, followed by <code>&body</code>, mimicking <code>With-Open-File</code> and the like. <syntaxhighlight lang="lisp">
(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))
,@body))
(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*)
nil)
(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
</syntaxhighlight>
* Function names ending in a <code>*</code> are minor variants of the same-named function without the star; eg, the standard <code>Let</code> and <code>Let*</code> 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 <syntaxhighlight lang="lisp">
(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")
</syntaxhighlight>
* Functions which operate on a subset selected by a predicate function usually have names ending in <code>-If</code> or <code>-If-Not</code>; eg, <code>Remove-If-Not</code>
* 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 <code>UIOP</code> has a package <code>UIOP</code>, as well as packages like <code>UIOP/Filesystem</code> and <code>UIOP/Stream</code>.
* Package names may follow the Java standard of reversed-top-level-domain prefixes; eg, <code>com.example.product.package</code>. 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 <code>Ensure-</code>Type-Name. eg: <code>(defun ensure-string (object) (princ-to-string object))</code> 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: <code>a->b</code>, <code>b<-a</code>, <code>b-from-a</code>, or <code>a-b</code>. The last form, with just a hyphen, mimics the standard functions <code>code-char</code> and <code>char-code</code>, but is a bit more ambiguous.
* The name <code>_</code> (and sometimes names like <code>__</code> or <code>_2</code> 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 <code>(declare (ignore _))</code>, so using a more meaningful name is usually preferred. <code>_</code> is most often used for <code>&rest</code> arguments. <syntaxhighlight lang="lisp">
#+sbcl
(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)))
</syntaxhighlight>
* 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 <code>message</code> rather than <code>m</code> (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 <code>$</code> to indicate a stringified representation of an object; eg, <code>(let ((number-of-hamsters$ (princ-to-string number-of-hamsters))) … )</code> or <code>(let ((number-of-hamsters (parse-integer number-of-hamsters$))) … )</code>
* Almost no-one will export a function (or variable) whose name conflicts with a name in the <code>Common-Lisp</code> package, since nearly every possible user will be in a package that has <code>(:use :common-lisp …)</code> in its definition.
* There are also rather strict conventions about indentation, comments, and formatting (inline) documentation which aren't really about naming things.
=={{header|Delphi}}==
The RTL capitalizes identifiers.
Identifiers denoting a type start with <tt>T</tt>, unless it’s a pointer to an already defined type.
Then the prefix is <tt>P</tt>.
Constants (not writable via {$W}) are shouted, although Pascal is case-insensitive.
=={{header|Dyalect}}==
Dyalect keywords, variables, constants and functions should be written using <code>camelCase</code>. This stays true for the module names. Type names, constructors and methods however use <code>PascalCase</code>:
<syntaxhighlight lang="dyalect">var xs = Array.Empty(10)
var ys = Array(1, 2, 3)
var str = xs.ToString()
type Maybe = Some(x) or None()
var x = Maybe.Some(42)</syntaxhighlight>
=={{header|Ecstasy}}==
<syntaxhighlight lang="java">
// a module name is the name of the app or library, followed by the domain name of the organization;
// alternatively, a "throw-away" module can have a simple name, like "TestApp"
module shop.acme.com {
// other than modules, all type and class names (including enum values) use upper CamelCase;
const Point(Int x, Int y);
enum Color {Red, Green, Blue}
interface Callback {
// variables, properties, methods, and functions using lower camelCase
Boolean active;
void onEvent(String event);
void onError(Exception e);
}
// constants use upper CamelCase, or in some cases, UPPER_SNAKE_CASE
String DefaultLogin = "guest";
Int MAX_QUANTITY = 100;
// type variables are named for their meanings, and use upper CamelCase
interface Bag<Element>
extends Iterable<Element> {
void add(Element e);
}
}
</syntaxhighlight>
=={{header|Factor}}==
Words are <code>named-with-dashes</code> instead of <code>named_with_underscores</code> or <code>namedWithCamelCase</code>. We tend to avoid abbreviating names. Since we typically don't name throwaway values, this improves clarity. Parsing words are <code>NAMED-LIKE-THIS:</code> so words that perform parse time look-ahead can be easily identified.
Since words can be named anything as long as they don't parse as a number or a string, word names follow an expressive mnemonic system, outlined below. This is not enforced in any way, but encouraged as a way to convey intent.
{| class="wikitable"
|-
! General form
! Description
! Examples
|-
| <tt>foo?</tt>
| outputs a boolean
| <tt>empty?</tt>
|-
| <tt>foo!</tt>
| a variant of <tt>foo</tt> which mutates one of its arguments
| <tt>append!</tt>
|-
| <tt>?foo</tt>
| conditionally performs <tt>foo</tt>
| <tt>?nth</tt>
|-
| <tt><foo></tt>
| creates a new <tt>foo</tt>
| <tt><array></tt>
|-
| <tt>>foo</tt>
| converts the top of the stack into a <tt>foo</tt> (generic)
| <tt>>array</tt>
|-
| <tt>foo>bar</tt>
| converts a <tt>foo</tt> into a <tt>bar</tt> (non-generic)
| <tt>number>string</tt>
|-
| <tt>new-foo</tt>
| creates a new <tt>foo</tt>, taking some kind of parameter from the stack which determines the type of the object to be created
| <tt>new-sequence, new-lexer, new</tt>
|-
| <tt>foo*</tt>
| alternative form of <tt>foo</tt>, or a generic word called by <tt>foo</tt>
| <tt>at*, pprint*</tt>
|-
| <tt>(foo)</tt>
| implementation detail word used by <tt>foo</tt> (helper word)
| <tt>(clone)</tt>
|-
| <tt>set-foo</tt>
| sets <tt>foo</tt> to a new value
| <tt>set-length</tt>
|-
| <tt>foo>></tt>
| gets the <tt>foo</tt> slot of the tuple at the top of the stack
| <tt>name>></tt>
|-
| <tt>>>foo</tt>
| sets the <tt>foo</tt> slot of the tuple at the top of the stack
| <tt>>>name</tt>
|-
| <tt>with-foo</tt>
| performs some kind of initialization and cleanup related to <tt>foo</tt>, usually in a new dynamic scope
| <tt>with-scope, with-input-stream, with-output-stream</tt>
|-
| <tt>$foo</tt>
| help markup
| <tt>$heading, $emphasis</tt>
|}
Stack effects also follow conventions. A stack effect of a word tells the stack effect checker how many objects a word takes from the stack and how many objects it leaves on the stack. For example, the stack effect for <code>+</code> looks like this: <code>( x y -- z )</code>. This declares that <code>+</code> takes two numbers from the stack and leaves one number on the stack. What you name these inputs and outputs does not matter to the stack effect checker; it only looks at how many inputs and outputs there are.
Inputs and outputs are typically named after some pun on their data type, or a description of the value's purpose if the type is very general.
{| class="wikitable"
|-
! Name
! Value
|-
| <tt>?</tt>
| a boolean
|-
| <tt><=></tt>
| an ordering specifier
|-
| <tt>m, n</tt>
| an integer
|-
| <tt>obj</tt>
| an object
|-
| <tt>quot</tt>
| a quotation
|-
| <tt>seq</tt>
| a sequence
|-
| <tt>assoc</tt>
| an associative mapping
|-
| <tt>str</tt>
| a string
|-
| <tt>x, y, z</tt>
| a number
|-
| <tt>loc</tt>
| a screen location specified as a two-element array holding x and y coordinates
|-
| <tt>dim</tt>
| a screen dimension specified as a two-element array holding width and height values
|-
| <tt>*</tt>
| when this symbol appears by itself in the list of outputs, it means the word unconditionally throws an error
|}
If a vocabulary is named <code>foo</code>, its source files should have the following names, as tools depend on this.
{| class="wikitable"
|-
! Main source file
! Tests
! Documentation
|-
| foo.factor
| foo-tests.factor
| foo-docs.factor
|}
=={{header|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.
<syntaxhighlight lang="text">\ 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
</syntaxhighlight>
====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.
<syntaxhighlight lang="text">\ 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
</syntaxhighlight>
=={{header|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:<
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.
Line 300 ⟶ 731:
===Function names===
*"D" is often used to indicate that
*"C" is often used to indicate that
*"Q" is often used to indicate that
And combinations can be applied...
*"CQ" is often used to indicate that
===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 <code>GO TO</code> is just as valid as <code>G OTO</code>. 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:
<
PRINT *,I
999 CONTINUE</
Notoriously, the U.S.A.'s first Venus satellite probe was lost due to the difference between <code>DO 3 I = 1.3</code> and <code>DO 3 I = 1,3</code> 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 <syntaxhighlight lang
<syntaxhighlight lang
=={{header|Free Pascal}}==
''See [[#Delphi|Delphi]] and [[#Pascal|Pascal]]''
=={{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|Go}}==
Go's naming conventions - like the language itself - are fairly simple.
1. Names of packages should consist of all lower case letters and, preferably, be brief.
2. Names of all other entities should be either 'mixedCaps' or 'MixedCaps' (no underscores).
3. Names which are exported from a package (i.e. public names) must begin with an upper case letter and be declared either at 'top level' within the package or be field or method names. All other names are not exported and hence are private to the package. This is not a convention, it is an obligatory part of the language.
4. If a struct has a private field, 'owner' say, public access to which is via by a getter and/or setter method, then the former should use the style Owner() and the latter SetOwner().
5. One method interfaces should take the name of the method and add the suffix 'er'. For example the Stringer interface contains the single method String().
For the purposes of the above conventions, 'letter' includes any recognized Unicode letter and is not therefore restricted to ASCII letters.
=={{header|Haskell}}==
Line 338 ⟶ 798:
Other conventions are also in use.
=={{header|Java}}==
According to Java's naming conventions, all names should be in mixed case:
classes and interfaces should be nouns beginning with a capital letter,
methods should be verbs beginning with a lower case letter,
variables should begin with a lower case letter.
Names should be descriptive, and single character names should be avoided except for short lived temporary variables.
Class variables which are static and final should be all upper case with words separated by underscores.
It is standard practice for an enum to be named in the same way as a class with its constants in all upper case.
The following program illustrates these naming conventions.
<syntaxhighlight lang="java">
import java.util.ArrayList;
import java.util.List;
public class NamingConventions {
public static void main(String[] arguments) {
SolarSystem solarSystem = new SolarSystem();
solarSystem.showSunDiameter();
System.out.println("The planetary system comprises of:");
solarSystem.listPlanets();
}
}
enum Planet { MERCURY, VENUS, EARTH, MARS, JUPITER, SATURN, URANUS, NEPTUNE, PLUTO }
class SolarSystem {
public SolarSystem() {
for ( Planet planet : Planet.values() ) {
planets.add(planet);
}
}
public void showSunDiameter() {
System.out.println("The diameter of the sun is approximately " + SOLAR_DIAMETER + " km");
}
public void listPlanets() {
System.out.println(planets);
}
private List<Planet> planets = new ArrayList<Planet>();
private static final int SOLAR_DIAMETER = 1_390_000;
}
</syntaxhighlight>
{{ out }}
<pre>
The diameter of the sun is approximately 1390000 km
The planetary system comprises of:
[MERCURY, VENUS, EARTH, MARS, JUPITER, SATURN, URANUS, NEPTUNE, PLUTO]
</pre>
=={{header|jq}}==
jq has some keywords (such as 'reduce') that impose certain restrictions on naming, but these are strictly enforced and so perhaps do not count as conventions. Similarly, there are strictly enforced restrictions regarding the use of the dollar-sign "$". Perhaps the most important convention to know about, therefore, is that identifiers beginning with "_" are reserved for internal use as function names, and should therefore not in general be used as such.
Although it is permissible and sometimes appropriate to define a function using the name of an existing built-in function, it is generally better to avoid doing so. With this in mind, it is useful to know that the built-in `builtins` emits a stream of strings representing the currently-defined built-ins. Furthermore, it is likely that future built-in functions will be named in accordance with existing practice, so it is useful to know that the names of built-in functions currently fall into one of these categories:
# names beginning with an underscore;
# names composed of lowercase letters [a-z] only;
# names such as `map_values`, that is, names composed of strings of lowercase letters joined by a single underscore;
# names of the form [a-z]+[0-9]+
# names composed only of uppercase letters [A-Z] (currently: IN, INDEX, JOIN)
# two exceptions: log1p, utf8bytelength
=== Variables ===
In 2017, the jq global $ARGS was introduced. It behaves as if it had been defined on the command-line. As with all such global variables, it can be shadowed.
=={{header|Julia}}==
In general, modules and type names use capitalization and camel case: module SparseArrays, struct UnitRange.
Variables and functions are lowercase (maximum, convert) and, when readable, with multiple words squashed together (isequal, haskey).
When necessary, use underscores as word separators. Underscores are also used to indicate a combination of concepts
(remotecall_fetch as a more efficient implementation of fetch(remotecall(...))) or as modifiers (sum_kbn).
Append ! to names of functions that modify their arguments.
Conciseness is valued, but avoid abbreviation (indexin rather than indxin) as it becomes difficult to remember whether and how particular words are abbreviated.
=={{header|Kotlin}}==
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:
<syntaxhighlight lang="scala">// version 1.0.6
const val SOLAR_DIAMETER = 864938
enum class Planet { MERCURY, VENUS, EARTH, MARS, JUPITER, SATURN, URANUS, NEPTUNE, PLUTO } // Yeah, Pluto!
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() {
println(planets)
}
}
fun main(args: Array<String>) {
val sun = Star("sun")
val ss = SolarSystem(sun)
sun.showDiameter()
println("\nIts planetary system comprises : ")
ss.listPlanets()
}</syntaxhighlight>
{{out}}
<pre>
The diameter of the sun is 864,938 miles
Its planetary system comprises :
[MERCURY, VENUS, EARTH, MARS, JUPITER, SATURN, URANUS, NEPTUNE, PLUTO]
</pre>
=={{header|Lambdatalk}}==
<syntaxhighlight lang="scheme">
Naming conventions
1) global names
- a name is a group of any character except space and curly braces {}
for instance "add", "+", "123", "()", "a.b.c", "...", ...
- but giving a variable the name of the 9 special forms (keywords)
["lambda", "def", "if", "let", "quote", "macro", "script", "style", "require"]
or of one of the more than 170 primitives
["div", ..., "+", ..., "cons", ..., A.new, A.first, A.rest, ..., long_add, ...]
is possible but is obviously strongly discouraged.
- when a function calls an helper function, it's better to prefix the helper function's name
with the calling function's name. For instance the function "fibonacci" sets
some initializations and calls the recursive part "fibonacci.rec".
- functions organized into sets (libraries) should be named with a common prefix.
For instance the set of functions working on complex numbers [ "C.new", "C.x", "C.y", "C.+", "C.*", ...],
suggesting object-oriented programming.
2) local names
Consider this example:
{def add {lambda {:a :b} :a+:b is equal to {+ :a :b}}}
-> add
{add 3 4}
-> 3+4 is equal to 7
When the add function is called the occurences of arguments {:a :b} are replaced by the given values, [3 4],
in the body of the function ":a+:b is equal to {+ :a :b}", leading to "3+4 is equal to {+ 3 4}" and finally
to "3+4 is equal to 7". Note that the character "a" inside the word "equal" has not been replaced.
So generally speaking:
- inside a function local defined arguments must be prefixed by a colon, ":",
- they must have a null intersection. For instance this arguments list {:a1 :a2} is valid
because the intersection of :a1 and :a2 is null, but this one {:a :a1} is not,
because the intersection of :a and :a1 is :a.
- an alternative could be to prefix and postfix names, say :a: and :a1: which have a null intersection.
It's a matter of choice let to the coder. In all cases naming must be done with the utmost care.
</syntaxhighlight>
=={{header|Lua}}==
Extract from https://github.com/zaki/lua-style-guide
- constants use UPCASE_SNAKE
- variable names use lower_case_snake
- class-like structures use CamelCase
- other functions use smallCamelCase
- Use _ for unneeded variables
- Don't use Hungarian Notation
<syntaxhighlight lang="lua">local DISTANCE_MAXIMUM = 1
local distance_to_target = 0
local function distanceToTarget() end
local function TargetFactory() end
for _,v in ipairs(table) do
print(v)
end</syntaxhighlight>
=={{header|M2000 Interpreter}}==
Identifiers need one letter at least, and any number of characters/numbers after.
If we use non break space as character: alfa beta=10 is a variable alfa beta (but here we get a copy with a space). To use non break space we press Shift+Ctrl+Space. To view it we can change rendering of internal text editor with F10 (show paragraph marks and different spaces). Shift+Alt+Space return Number's space.
M2000 is like Basic, identifiers are case insensitive. For Greek names also accent marks can be used freely (so a fault accent mark isn't a fault for interpreter).
Labels although are case sensitive
We have to use $ as last character in names for anything return string. We can use % as last character for integers (as values, because under it maybe double or something else, depends of the first value we assign it).
We use <= to assign values to global variables, because = make new variables and shadow any global with same name.
We use <= for group members also inside functions which are members too.
Arrays didn't use <= to get values.
Groups which return strings also have to use $ in names, but these have two names as in this example:
<syntaxhighlight lang="m2000 interpreter">
Class Alfa$ {
Private:
myValue$
Public:
Set {
Read .myValue$
}
Value {
=.myValue$
}
Module Doit {
Function TwoChars$(A$) {
=Left$(Left$(a$,1)+Right$(a$,1)+"??",2)
}
Print TwoChars$(.myValue$)
Dim A$(3)
A$(0)="zero","one","two"
Print A$(1)
k$=Lambda$ A$() (x) -> {
if x>0 and x<3 then {=A$(x)} else =A$(0)
}
Print k$(2)
Dim A$()
Print Len(A$())=0
Print k$(2)="two"
}
}
A$=Alfa$()
Module CheckIt(&B$) {
Input "name:", B$
B.Doit
}
Checkit &A$
Print A$
</syntaxhighlight>
=={{header|Mathematica}}/{{header|Wolfram Language}}==
All built-in Mathematica commands are case sensitve and written in camel case. Most are full english words. For example: FactorInteger, ListPlot, AsynchronousTaskObject etc.
A small number of abbreviation conventions are used: Predicates end in Q, eg PrimeQ, EvenQ, MatrixQ, numerical routines start with N, eg NSolve, NLimit, NMinimize. System variables start with $PreferencesDirectory, $TimeZone, $Version etc.
Convention is that user variables and function names also also cammel case except they start with a lower case. eg myFunctionName. There is no limit to the number of characters in a user symbol, symbols can contain digits and non-ascii characters.
=={{header|MIPS Assembly}}==
* Registers typically start with a dollar sign, e.g. <code>$a0</code>, <code>$ra</code>, etc. Not all assemblers require this.
* Constants are usually in all capitals.
* Function names are often in CamelCase with the first letter being lowercase.
* <code>byte</code> is 8-bit, <code>halfword</code> is 16-bit, and <code>word</code> is 32-bit. However, it is up to the programmer to correctly use the data. The CPU never sees these declarations once the program is assembled, so there's nothing stopping you from loading data at the "wrong" length.
=={{header|Nim}}==
Nim has precise guidelines for naming. Here is an extract of the style guide.
:- Type identifiers should be in PascalCase. All other identifiers should be in camelCase with the exception of constants which may use PascalCase but are not required to.
<syntaxhighlight lang="nim"># Constants can start with either a lower case or upper case letter.
const aConstant = 42
const FooBar = 4.2
var aVariable = "Meep" # Variables must start with a lowercase letter.
# Types must start with an uppercase letter.
type
FooBar = object</syntaxhighlight>
:- When naming types that come in value, pointer, and reference varieties, use a regular name for the variety that is to be used the most, and add a "Obj", "Ref", or "Ptr" suffix for the other varieties. If there is no single variety that will be used the most, add the suffixes to the pointer variants only.
:- Exception and Error types should have the "Error" or "Defect" suffix.
:- Unless marked with the {.pure.} pragma, members of enums should have an identifying prefix, such as an abbreviation of the enum's name.
<syntaxhighlight lang="nim">type
PathComponent = enum
pcDir
pcLinkToDir
pcFile
pcLinkToFile</syntaxhighlight>
:- Non-pure enum values should use camelCase whereas pure enum values should use PascalCase.
<syntaxhighlight lang="nim">type
PathComponent {.pure.} = enum
Dir
LinkToDir
File
LinkToFile</syntaxhighlight>
=={{header|OASYS Assembler}}==
Line 382 ⟶ 1,149:
Examples: loop: , for: , new: , ...
=={{header|
Pascal is a strongly typed language.
It likes to encourage the programmer to write what is ''meant'', not what the underlying structure is.
Since identifiers are case-insensitive, PascalCase is one, if not ''the'' capitalization strategy most programmers adhere to.
See also [[#Delphi|Delphi]] and [[#Free Pascal|Free Pascal]].
=={{header|Perl}}==
This being Perl, you are of course give wide latitude in the names you can use for your program elements.
But it can be helpful to other programmers, and possibly your future self, to use letter case and underscores
to indicate the scope and nature of variable and routines, so their roles can be understood at a glance.
Some generally accepted conventions:
$ALL_CAPS_HERE constants
$Some_Caps_Here package-wide global/static
$no_caps_here function scope my/our/local variables
$_internal_use private
Note the use of underscores for readability.
Subroutines and variables meant to be treated as private can be prefixed with an underscore.
With all-caps constants, be careful for conflicts with Perl special variables.
Function and method names should be all lowercase.
Any reasonably modern version of Perl can use Unicode characters in names, so employ them where it makes sense. It
may be necessary to invoke the <code>use utf8</code> pragma that case.
<b>A caution about variables names and sigils</b>:
Perl won't stop you from giving three variables in the same scope the names
<code>%foo</code>, <code>@foo</code> and <code>$foo</code>, but that doesn't
mean it's a good idea. Here's a good example of [https://gist.github.com/SqrtNegInf/df5fbab044babc6ca16e229d2d1c669f what not to do] (offsite Perl code)
=={{header|Phix}}==
Conventions are not strictly enforced.<br>
Builtin and library routines are full english lowercase words and underscore separated, eg custom_sort()<br>
Function-style invocation is common instead of infix operators for less-used and new features, eg power(3,5)<br>
Constants are often uppercase, eg PI<br>
Keywords are always lowercase, eg while<br>
The end keyword always has an explicit match, eg end while<br>
Variable names are case-sensitive and may not contain any embedded operators or spaces<br>
Over-loading or over-riding the names of variables and routines is generally frowned upon<br>
All unicode characters are permitted, via what turned out to be fairly trivial mods to ptok.e<br>
The pGUI.e library retains the original IUP C names, eg IupDialog<br>
File extensions generally imply the following:<br>
.e - general purpose include, not executable standalone<br>
.ew - windows-only include<br>
.eu - linux-only include<br>
.exw - historically this implied windows-only, but is now also used for any cross-platform gui applications.<br>
=={{header|Phixmonti}}==
No naming conventions. All is only words, numbers, lists or strings (delimited by double quotation marks) separated by blanks. Caution! redefine words is not reversible.
<syntaxhighlight lang="Phixmonti">def *'#-? "Hello world" print enddef
*'#-? nl
10 var +{&
+{& print
5 var + /# redefine + to variable with value 5. Aritchmetic word is missing #/
+ print</syntaxhighlight>
{{out}}
<pre>Hello world
10
5
=== Press any key to exit ===</pre>
=={{header|PicoLisp}}==
Line 435 ⟶ 1,251:
* Private member functions are embeded between "__" to make a member function "private".
* Variables are generally lower-case.
=={{header|Quackery}}==
Names in Quackery are any sequence of printable characters, delimited by non-printable characters (i.e. spaces and carriage returns). The Quackery compiler identifies builders, words and numbers by searching first the builders and then the words dictionaries, each from most recently to least recently defined name, and either executes the builder or compiles the word, or if not found, attempts to parse the token as a number. New builders and names can be added to the dictionaries using the builders <code>builds</code> and <code>is</code> respectively. Dictionary searches are case sensitive, number parsing is not (this is relevant for times when the current base is set to larger than 10 during compilation.)
To avoid confusion between words and numbers, where applicable, numbers should exclusively include upper case letters along with any digits, and words should not.
=={{header|Racket}}==
Line 442 ⟶ 1,264:
The convention is to use full English lowercase words separated by dashes
<
render-game-state
send-message-to-client
traverse-forest</
Usually <code>_</code> is used only as the name of a dummy argument.
Line 451 ⟶ 1,273:
Most functions names have as prefix the data type of the main argument. Some notable exceptions are the functions for <code>list</code>s and <code>box</code>es, for backward compatibility.
<
(string-ref "1234" 2)
(string-length "123")
Line 457 ⟶ 1,279:
;exceptions:
(append (list 1 2) (list 3 4))
(unbox (box 7))</
This convention generalizes the selector-style naming scheme of <code>struct</code>s.
<
(struct pair (x y) #:transparent #:mutable)
(define p (pair 1 2))
Line 467 ⟶ 1,289:
(set-pair-y! p 3)
p ; ==> (pair 1 3)
</syntaxhighlight>
The name of conversion procedure is usually like <code>from->to</code>
<
(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:
<syntaxhighlight lang="racket">
;predicates and boolean-valued functions: ?
(boolean? 5)
Line 491 ⟶ 1,313:
;interfaces: <%>;
dc<%>;
font-name-directory<%></
=={{header|Raku}}==
(formerly Perl 6)
Raku is written in Unicode, and has consistent Unicode semantics regardless of the underlying text representations. By default Raku 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 Raku 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 Raku 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. Identifiers 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. Descriptiveness 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. Finally, if you ''aren't'' going to follow convention, at least be consistent.
=={{header|REXX}}==
Line 507 ⟶ 1,347:
Values that conform to the REXX definition of a number (below) are treated as a number:
The '''e''' or '''E''' (above) signifies the following decimal number is an exponent (a power of ten that
<br>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,
<br>with/without an optional sign.
===variable names===
Line 546 ⟶ 1,389:
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
<br>function can be invoked using its name as an
<
say "length(s) =" length(s) /*
say "'LENGTH'(s) =" 'LENGTH'(s) /*
exit
length: return 1000</syntaxhighlight>
{{out|output}}
length(s) = 1000
'LENGTH'(s) = 4
</pre>
===label names===
Line 578 ⟶ 1,424:
<br>case may be used interchangeably.
<br><br>
=={{header|Ruby}}==
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
<code>HelloWorld</code> is different from <code>helloworld</code>.
===Variable Names===
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 <code>time_of_day</code>. Instance variables begin with <code>@</code>, class variables begin with <code>@@</code> and global variables begin with <code>$</code>
===Constants===
In ruby, constants must begin 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 <code>RECURSION_LIMIT</code>.
===Method names===
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, <code>1.positive?</code> or <code>'test'.tainted?</code>. Also, so called <i>destructive</i> methods end with an exclamation point. For example,
<syntaxhighlight lang="ruby">
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]
</syntaxhighlight>
The <code>sort</code> method just returns a sorted version of the array, but the <code>sort!</code> 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 <code>field_name</code> and the proper naming convention for a setter is <code>field_name=</code>. An example of this will be seen later on in this description. Constructors are always named <code>initialize</code>.
===Classes and Modules===
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===
Here is an example of a ruby file with proper naming conventions being used.
<syntaxhighlight lang="ruby">
# Global variable
$number_of_continents = 7
module Banking
# Module constants for semantic versioning
VERSION = '1.0.0.1'
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
end
# Explicit setter as extra behavior is required
def account_number=(account_number)
puts 'Enter administrator override'
if gets == @@adiministrator_password
@account_number = account_number
else
puts 'Sorry. Incorrect password. Account number not changed'
end
end
# Explicit getter as extra behavior is required
def balance
"$#{@balance / 100}.#{@balance % 100}"
end
# Check if account has sufficient funds to complete transaction
def sufficient_funds? (withdrawal_amount)
withdrawal_amount <= @balance
end
# Destructive method
def donate_all_money!
@balance = 0
end
end
end
</syntaxhighlight>
=={{header|Rust}}==
* Crates (libraries) are either <tt>snake_case</tt> or <tt>kebab-case</tt>.
* Types, traits and enum variants are <tt>PascalCase</tt>.
* Consts and statics are <tt>SCREAMING_SNAKE_CASE</tt>.
* Functions, variable bindings, struct members and almost everything else is <tt>snake_case</tt>.
Detailed information can be found in the [https://rust-lang.github.io/api-guidelines/naming.html Rust API Guidelines.]
=={{header|Scala}}==
An excellent documentation about naming is given in [https://docs.scala-lang.org/style/naming-conventions.html the Scala Style Guide.]
=={{header|Tcl}}==
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: [http://wiki.tcl.tk/10259 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.
=={{header|Visual Basic}}==
<!-- Naming conventions -->
Microsoft was encouraging [https://en.wikipedia.org/wiki/Camel_case camelCase] in Visual Basic. And at the beginning Microsoft was also encouraging programmers to use [https://en.wikipedia.org/wiki/Hungarian_notation Hungarian notation].<br>
'''Camel case:'''<br>
The variable name begins with a prefix and has one or more uppercase inside.
<syntaxhighlight lang="vb">Dim dblDistance as Double</syntaxhighlight>
'''Hungarian notation:'''
<syntaxhighlight lang="vb">Dim iRow as Integer, iColumn as Integer
Dim sName as String
Dim nPopulation as Long
Dim xLightYear as Double
iRow = iRow + 1</syntaxhighlight>
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.<br>
The real advantage is for the names of the VB controls.
{| class="wikitable"
|-
! Prefix
! Meaning
|-
| <tt>frm</tt>
| <tt>Form</tt>
|-
| <tt>mnu</tt>
| <tt>Menu</tt>
|-
| <tt>cmd </tt>
| <tt>Command button</tt>
|-
| <tt>chk</tt>
| <tt>Check button</tt>
|-
| <tt>opt</tt>
| <tt>Radio button</tt>
|-
| <tt>lbl</tt>
| <tt>Text label</tt>
|-
| <tt>txt</tt>
| <tt>Text edit box</tt>
|-
| <tt>pic</tt>
| <tt>Picture</tt>
|-
| <tt>cbo</tt>
| <tt>Combo box</tt>
|-
| <tt>tmr</tt>
| <tt>Timer</tt>
|-
| <tt>...</tt>
| <tt>...</tt>
|}
Exemple:
<syntaxhighlight lang="vb">txtTraduc.Width = iWidth
cmdSolution.Enabled = False
mnuAleatoire.Checked = False
frmScore.Show vbModal
picFace.Visible = False
picFace.Picture = LoadPicture(sFileName)</syntaxhighlight>
The advantage comes clear for the “Private Sub” names of the controls:
<syntaxhighlight lang="vb">mnuQuit_Click()
cmdSolution_Click()
frmScore_Resize()</syntaxhighlight>
=={{header|Wren}}==
The 'official' naming conventions for Wren are as follows:
* Class names begin with an upper case letter.
* Method names begin with a lower case letter.
* Instance field names begin with an underscore.
* Static field names begin with a double underscore.
<br>
Only the last two are strictly enforced - there is no other way to define fields and it is not possible to name any other kind of entity with a leading underscore.
However, if you don't stick to the naming conventions for classes and methods, you may get some strange errors as Wren expects any names beginning with a lower case letter to be found within the class and any beginning with an upper case letter to be found outside the class and will issue an error if it can't find them. This needs to be borne in mind when naming global variables or functions which you want to use inside a class.
In the standard library, names are camel cased.
Local variables, parameters and functions usually have names written in lower camel case.
Module names are generally lower snake case.
Although unofficial, one often sees the following conventions used:
* Methods which are not intended to be called from outside the class have names suffixed with an underscore.
* Variables which are not intended to be mutated (Wren doesn't have constants as such) have names written in upper snake case.
=={{header|XPL0}}==
Identifier names (used for variables, constants, and subroutines) can
contain letters (A-Z, a-z), numbers (0-9), and underlines (_); but they
must start with an upper-case letter or an underline. Names can be any
length, but only the first 16 characters are recognized by the compilers.
Upper- and lower-case letters are treated as equivalent (i.e. names are
case-insensitive).
Requiring names to start with a capital letter prevents conflict with
command words. For instance, "While" can be a variable name.
By convention CamelCase is used. For example, RateOfReturn is preferred
over Rate_of_return or RATE_OF_RETURN, although all are legal (and the
last two are treated as the same name).
When XPL0 was first created, it ran on computers like the Apple ][ that
didn't have lower-case letters. Single quotes were used to effectively
shift upper case to lower case. Thus the reserved word "while" was
written as 'WHILE'. The ability of single quotes to shift case was
dropped when computers with lower case became standard. On those old
computers only the first six characters were recognized in names.
As XPL0 evolved identifier names increased from six to 16 characters, and
more descriptive names were used for new intrinsic routines. For example,
the early intrinsic that ran the speaker at various frequencies is called
Sound, whereas a recent intrinsic that plays MP3 files is called
PlaySoundFile.
A subtle convention uses short names (such as I for index and X and Y for
coordinates) for local variables, and longer more descriptive names for
global variables.
=={{header|Zig}}==
Zig is a new (pre-1.0) language, so it hasn't had opportunity to gather naming cruft.
Here are the naming conventions taken from the Zig documentation:
Roughly speaking: camelCaseFunctionName, TitleCaseTypeName, snake_case_variable_name. More precisely:
* If x is a type then x should be TitleCase, unless it is a struct with 0 fields and is never meant to be instantiated, in which case it is considered to be a "namespace" and uses snake_case.
* If x is callable, and x's return type is <code>type</code>, then x should be TitleCase.
* If x is otherwise callable, then x should be camelCase.
* Otherwise, x should be snake_case.
Acronyms, initialisms, proper nouns, or any other word that has capitalization rules in written English are subject to naming conventions just like any other word. Even acronyms that are only 2 letters long are subject to these conventions.
File names fall into two categories: types and namespaces. If the file (implicitly a struct) has top level fields, it should be named like any other struct with fields using TitleCase. Otherwise, it should use snake_case. Directory names should be snake_case.
;Examples:
<syntaxhighlight lang="zig">
const namespace_name = @import("dir_name/file_name.zig");
const TypeName = @import("dir_name/TypeName.zig");
var global_var: i32 = undefined;
const const_name = 42;
const primitive_type_alias = f32;
const string_alias = []u8;
const StructName = struct {
field: i32,
};
const StructAlias = StructName;
fn functionName(param_name: TypeName) void {
var functionPointer = functionName;
functionPointer();
functionPointer = otherFunction;
functionPointer();
}
const functionAlias = functionName;
fn ListTemplateFunction(comptime ChildType: type, comptime fixed_size: usize) type {
return List(ChildType, fixed_size);
}
fn ShortList(comptime T: type, comptime n: usize) type {
return struct {
field_name: [n]T,
fn methodName() void {}
};
}
// The word XML loses its casing when used in Zig identifiers.
const xml_document =
\\<?xml version="1.0" encoding="UTF-8"?>
\\<document>
\\</document>
;
const XmlParser = struct {
field: i32,
};
// The initials BE (Big Endian) are just another word in Zig identifier names.
fn readU32Be() u32 {}
</syntaxhighlight>
These are general rules of thumb; if it makes sense to do something different, do what makes sense. For example, if there is an established convention such as <code>ENOENT</code>, follow the established convention.
=={{header|zkl}}==
| |||