Naming conventions: Difference between revisions
Rename Perl 6 -> Raku, alphabetize, minor clean-up
(Added XPL0 example.) |
Thundergnat (talk | contribs) (Rename Perl 6 -> Raku, alphabetize, minor clean-up) |
||
Line 337:
- 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}}==
Line 456 ⟶ 460:
* There are also rather strict conventions about indentation, comments, and formatting (inline) documentation which aren't really about naming things.
▲=={{header|Clojure}}==
▲* [https://github.com/bbatsov/clojure-style-guide The Clojure Style Guide]
=={{header|Delphi}}==
Line 663:
In Fortran 77 then <lang fortran>IMPLICIT NONE</lang> was available to disable implicit typing and thus evoke "undeclared variable" messages. Prior to this the code could use
<lang fortran>IMPLICIT LOGICAL</lang> in the hope that the compiler would detect an undeclared LOGICAL variable used in a numerical context, and hence report a semantic type error.
=={{header|Free Pascal}}==▼
''See [[#Delphi|Delphi]] and [[#Pascal|Pascal]]''▼
=={{header|FreeBASIC}}==
Line 674 ⟶ 677:
As long as a consistent style is used, code readability does not seem to be an issue.
▲=={{header|Free Pascal}}==
▲''See [[#Delphi|Delphi]] and [[#Pascal|Pascal]]''
=={{header|Go}}==
Line 942:
<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|Perl 6}}==▼
Perl 6 is written in Unicode, and has consistent Unicode semantics regardless of the underlying text representations. By default Perl 6 presents Unicode in "NFG" formation, where each grapheme counts as one character. A grapheme is what the user would think of as a character in their normal everyday life, including any diacritics.▼
Built-in object types start with an uppercase letter. This includes immutable types (e.g. Int, Num, Complex, Rat, Str, Bit, Regex, Set, Block, Iterator), as well as mutable (container) types, such as Scalar, Array, Hash, Buf, Routine, Module, and non-instantiable Roles such as Callable and Integral. The names may extend to CamelCase for compound words: IntStr, CaptureCursor, BagHash, SoftRoutine.▼
Non-object (native) types are lowercase: int, num, complex, rat, buf, bit.▼
Nearly all built-in subroutines, functions, methods and pragmas included in Perl 6 CORE are lowercase or lower kebab-case. (Compound words joined with hyphens rather than underscores or camelCase.) .grep, .pairs, .log, .defined, .subst-rw. The few notable exceptions are those which can radically change behaviour of the executing code. They are in all-cap/kebab-case to make them stand out: EVAL, MONKEY-TYPING.▼
All upper case names are semi-reserved. You are free to use them, but are warned that you may encounter future collisions with internal usage. Upper case names are used for pseudo-packages: MY, OUR, CORE, GLOBAL, etc., for relative scope identifiers: CALLER, OUTER, SETTING, PARENT, etc. and other things.▼
Variables in Perl 6 CORE tend be lower kebab-case for lexical variables and upper case for special or package globals. They have an attached, prefix sigil (or twigil) to indicate what type of object they hold and what methods are available to operate on them.▼
In user space, there are very few restrictions on how things are named. Identifers of any type can not contain white space. Subroutines must start with a letter character, any unicode character that has a "letter" property. Variable names can't contain any of the sigil, twigil or comment characters ($, @, %, *, ?, =, :, #). Outside of those few restrictions, it's pretty much a free-for-all.▼
That being said, there are some community conventions which are encouraged, though not enforced. Descriptivness is favoured over terseness, though this should be scaled to the scope of the object. It is perfectly fine to name an index variable in a three line loop, $i. An object in global scope with dozens of methods may be better off with a more descriptive name. It is encouraged to name subroutines for what they do to make it easier for others to follow your logic. Nouny things should have nouny names. Verby things should be verby. If you ''aren't'' going to follow convention, at least be consistent.▼
=={{header|Phix}}==
Line 1,073 ⟶ 1,056:
font-name-directory<%></lang>
(formerly Perl 6)
▲Perl 6 is written in Unicode, and has consistent Unicode semantics regardless of the underlying text representations. By default Perl 6 presents Unicode in "NFG" formation, where each grapheme counts as one character. A grapheme is what the user would think of as a character in their normal everyday life, including any diacritics.
▲Built-in object types start with an uppercase letter. This includes immutable types (e.g. Int, Num, Complex, Rat, Str, Bit, Regex, Set, Block, Iterator), as well as mutable (container) types, such as Scalar, Array, Hash, Buf, Routine, Module, and non-instantiable Roles such as Callable and Integral. The names may extend to CamelCase for compound words: IntStr, CaptureCursor, BagHash, SoftRoutine.
▲Non-object (native) types are lowercase: int, num, complex, rat, buf, bit.
▲Nearly all built-in subroutines, functions, methods and pragmas included in Perl 6 CORE are lowercase or lower kebab-case. (Compound words joined with hyphens rather than underscores or camelCase.) .grep, .pairs, .log, .defined, .subst-rw. The few notable exceptions are those which can radically change behaviour of the executing code. They are in all-cap/kebab-case to make them stand out: EVAL, MONKEY-TYPING.
▲All upper case names are semi-reserved. You are free to use them, but are warned that you may encounter future collisions with internal usage. Upper case names are used for pseudo-packages: MY, OUR, CORE, GLOBAL, etc., for relative scope identifiers: CALLER, OUTER, SETTING, PARENT, etc. and other things.
▲Variables in Perl 6 CORE tend be lower kebab-case for lexical variables and upper case for special or package globals. They have an attached, prefix sigil (or twigil) to indicate what type of object they hold and what methods are available to operate on them.
▲In user space, there are very few restrictions on how things are named. Identifers of any type can not contain white space. Subroutines must start with a letter character, any unicode character that has a "letter" property. Variable names can't contain any of the sigil, twigil or comment characters ($, @, %, *, ?, =, :, #). Outside of those few restrictions, it's pretty much a free-for-all.
▲That being said, there are some community conventions which are encouraged, though not enforced. Descriptivness is favoured over terseness, though this should be scaled to the scope of the object. It is perfectly fine to name an index variable in a three line loop, $i. An object in global scope with dozens of methods may be better off with a more descriptive name. It is encouraged to name subroutines for what they do to make it easier for others to follow your logic. Nouny things should have nouny names. Verby things should be verby. If you ''aren't'' going to follow convention, at least be consistent.
=={{header|REXX}}==
Line 1,245:
=={{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).
Line 1,334 ⟶ 1,335:
cmdSolution_Click()
frmScore_Resize()</lang>
=={{header|XPL0}}==
Line 1,367:
coordinates) for local variables, and longer more descriptive names for
global variables.
=={{header|zkl}}==
| |||