Naming conventions: Difference between revisions

From Rosetta Code
Content added Content deleted
m (→‎{{header|ALGOL 68}}: add char codes & more print/put/read/get examples)
Line 242: Line 242:
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 <code>hfd</code> (meaning ''hexadecimal from decimal'').
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 <code>hfd</code> (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. This makes it a bit easier to use the original documentation.
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.
Other conventions are also in use.

Revision as of 09:53, 30 September 2015

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

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

Fortran

Every Fortran variable has an implicit type determined by the first letter of the variable. The implicit types are as follows. <lang fortran>IMPLICIT REAL(A-H,O-Z), INTEGER(I-M)</lang>

The implicit declaration sometimes lead to problems with misspelled variables (and typos) being accidentally implicitly declared in a program and resulting in (hard to find) code bugs. For example the output from the program isn't all the integers from 1 to 10: <lang fortran> DO 999 I=1 10

       PRINT *,I

999 CONTINUE</lang>

The next effect is that loop variable are typically one of I, J, K, L, M, N

Functions
  • "D" is often used to indicate that a INTRINSIC FUNCTION returns a DOUBLE PRECISION REAL number. e.g. "cosine" in DOUBLE precision is DCOS"
  • "Q" is often used to indicate that a INTRINSIC FUNCTION returns a QUAD PRECISION REAL number. e.g. "cosine" in QUAD precision is QCOS"
  • "C" is often used to indicate that a INTRINSIC FUNCTION returns a COMPLEX number. e.g. "cosine" QUAD COMPLEX use DCCOS

And combinations can be applied...

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

In Fortran 77 then <lang fortran>IMPLICIT NONE</lang> was available to disable implicit typing, prior to this the code could use <lang fortran>IMPLICIT LOGICAL</lang> in the hope that the compile would detect an undeclared LOGICAL variable numerical context, hence report a semantic type error.

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.

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.

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.