Naming conventions: Difference between revisions

;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' ¢;

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

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

Note: The type returned by the '''proc'''edure is generally prefixed to the '''proc'''edure name.

'''od'''

|| Quote stropping<br/>(like [[wp:Lightweight markup language#Text/font-face formatting|wikitext]])

'pr' quote 'pr'

'mode' 'xint' = 'int';

sum sq+:=i↑2

'od'

|| For a [[wp:List of binary codes#Seven-bit binary codes|7-bit]] character code compiler

.PR UPPER .PR

MODE XINT = INT;

sum sq+:=i**2

OD

|| For a [[wp:Six-bit character code|6-bit]] character code compiler

.PR POINT .PR

.MODE .XINT = .INT;

SUM SQ .PLUSAB I .UP 2

.OD

|| Algol68 using '''res''' stropping<br/>(reserved word)

.PR RES .PR

mode .xint = int;

sum sq+:=i↑2

od

|}

Note that spaces are permitted in constants, variable and '''proc'''edure names.

=={{header|AntLang}}==

=={{header|Arturo}}==

=={{header|AWK}}==

# Field names begin with $ so $1 is the first field, $2 the second and $NF the

# last. $0 references the entire input record.

# special files:

# /dev/stdin /dev/stdout /dev/error

=={{header|BASIC}}==

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.

;Libraries

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 "__":

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

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

double complex ccos(double complex z);

float complex ccosf(float 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, ...);

int vfprintf(FILE *stream, const char *format, va_list ap);

int vsprintf(char *str, const char *format, va_list ap);

;Function names

'''Naming'''<br/>

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

Mercury, Venus, Earth, Mars, Jupiter, Saturn, Uranus, Neptune

}

Workdays = Monday | Tuesday | Wednesday | Thursday | Friday

AllWeek = Sunday | Saturday | Workdays

You should:<br/>

- prefix interface names with I e.g. IPrinter

- postfix type names that inherit from EventArgs, Exception, Attribute and EventHandler e.g. MouseMoveEventArgs<br/>

- postfix async method names with Async e.g. GetDataAsync()

* Type names for errors or warnings usually explicitly have the word “warning” or “error” in the name, eg, <code>Server-Unreachable-Error</code>

(defvar *language* :en

"The language to use for messages (defaults to English)")

Hace demasiado frío en invierno

It's too cold in winter

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

(defun do-something (argument &key ((secret-arg secret) "default"))

(format t "Argument is ~a, secret is ~a" argument secret))

;; Special caller:

(do-something "Foo" 'secret-arg "Bar")

* 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>

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

#+sbcl

(defun user-name+home-phone (user-id)

(declare (ignore office office-phone _))

(values real-name home-phone)))

* Argument names are usually self-documenting; since most IDE's will show the argument names in some way (eg: Emacs shows them in the mode line after a function name is entered), using a name like <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.

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>:

var ys = Array(1, 2, 3)

var str = xs.ToString()

type Maybe = Some(x) or None()

=={{header|Factor}}==

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

VARIABLE MYINT1

VARIABLE MYINT2

HR_RECORD 992 PERSONEL RECORD! \ store HR_RECORD

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

: buffer: ( bytes -- ) create allot ;

hex 100 buffer: mybuffer \ buffer: creates a new WORD in the dictionary call mybuff

m: clear 0 swap ! ;m

;class

=={{header|Fortran}}==

===From the beginning===

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.

===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

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

=={{header|Free Pascal}}==

The following program illustrates these conventions:

const val SOLAR_DIAMETER = 864938

println("\nIts planetary system comprises : ")

ss.listPlanets()

{{out}}

=={{header|Lambdatalk}}==

Naming conventions

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

=={{header|Lua}}==

- Use _ for unneeded variables

- Don't use Hungarian Notation

local distance_to_target = 0

local function distanceToTarget() end

for _,v in ipairs(table) do

print(v)

=={{header|M2000 Interpreter}}==

Groups which return strings also have to use $ in names, but these have two names as in this example:

Class Alfa$ {

Private:

Checkit &A$

Print A$

=={{header|Mathematica}}/{{header|Wolfram Language}}==

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

const aConstant = 42

const FooBar = 4.2

# Types must start with an uppercase letter.

type

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

:- Unless marked with the {.pure.} pragma, members of enums should have an identifying prefix, such as an abbreviation of the enum's name.

PathComponent = enum

pcDir

pcLinkToDir

pcFile

:- Non-pure enum values should use camelCase whereas pure enum values should use PascalCase.

PathComponent {.pure.} = enum

Dir

LinkToDir

File

=={{header|OASYS Assembler}}==

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

render-game-state

send-message-to-client

Usually <code>_</code> 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 <code>list</code>s and <code>box</code>es, for backward compatibility.

(string-ref "1234" 2)

(string-length "123")

;exceptions:

(append (list 1 2) (list 3 4))

This convention generalizes the selector-style naming scheme of <code>struct</code>s.

(struct pair (x y) #:transparent #:mutable)

(define p (pair 1 2))

(set-pair-y! p 3)

p ; ==> (pair 1 3)

The name of conversion procedure is usually like <code>from-&gt;to</code>

(list->vector '(1 2 3 4))

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

;predicates and boolean-valued functions: ?

(boolean? 5)

;interfaces: <%>;

dc<%>;

=={{header|Raku}}==

For example:

─── where &nbsp; '''length''' &nbsp; is a REXX BIF for the &nbsp; ''length'' &nbsp; of the &nbsp; value &nbsp; of the variable &nbsp; '''ABC'''

If there is an internal function with a built-in function's name in the program, &nbsp; the built-in (REXX)

<br>function can be invoked using its name as an uppercase literal string as shown below:

say "length(s) =" length(s) /* ──► 1000 */

say "'LENGTH'(s) =" 'LENGTH'(s) /* ──► 4 */

exit

{{out|output}}

<pre>

===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,

test_variable = [1, 9, 8, 3]

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

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

test_variable # => [1, 3, 8, 9]

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

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

# Global variable

$number_of_continents = 7

end

end

=={{header|Rust}}==

'''Camel case:'''<br>

The variable name begins with a prefix and has one or more uppercase inside.

'''Hungarian notation:'''

Dim sName as String

Dim nPopulation as Long

Dim xLightYear as Double

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.

|}

Exemple:

cmdSolution.Enabled = False

mnuAleatoire.Checked = False

frmScore.Show vbModal

picFace.Visible = False

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

cmdSolution_Click()

=={{header|Wren}}==

;Examples:

const namespace_name = @import("dir_name/file_name.zig");

const TypeName = @import("dir_name/TypeName.zig");

// The initials BE (Big Endian) are just another word in Zig identifier names.

fn readU32Be() u32 {}

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.