some procedure or function

for inner parts of a procedure that are called recursively

for unspecified, in some way related bindings or arguments in obvious scope

(list-sort (l (a b) (< a b)) books)

• one reasoning is, that if one does not give something a descriptive name, then the next best thing is to at least give it a generic name that can be recognised as such
• keeping alphabetical order when introducing those bindings can help to find the places where they are bound to values

• also used for elements of a collection in expressions where it has mostly structural relevance, like in (map (l (a) (+ 1 a)) books)

  • it needs to be clear that "a" is a "book". in this example the identifier for the collection "books" is near
  • naming it explicitly "book" would make the naming of the inner structure dependent on the outer structure and require renaming if it is copied or the outside changes. using dependent names creates more trouble than an explicit naming would be useful in this case
  • it shortens the code significantly without using other invented abbreviations and makes the presumably more important structure more visible
• "item" is not necessarily a better word to use (see english language dictionary)

for a continuation procedure. for procedures that use continuation-passing-style. that means, they pass on results to a procedure that will determine the final return value example. conflicts with the abc variables though

(define (integer-and-fraction number c)
  ; ...calculations...
  (c integer fraction))

(integer-and-fraction 3.72 (l (integer fraction) #t))

• example: list-sort, vector-ref
• list procedures might be ok without a data-type prefix because lists are a very fundamental data-type in scheme

using a "namespace" name, for example the last part of a module name, for a set of procedures

for everything that can be considered the rest of something. might be used as a suffix (l (a . a-rest) #t)

the result of a procedure or similar. usually in cases where things have to happen before the result is returned but after it has been created

• for word separation
• separate words should be infixed. sometimes it can be difficult to decide where to separate. for example is it filename or file-name?
• the minus to separate words in identifiers is widely employed in scheme (vector-* list-* hashtable-*) and it has a consistency benefit to use it
• no "camelcase" - camelcase takes 26 additional symbols as 26 different word delimiters to make identifiers less readable, more difficult to type (shift key and the pressing of simultaneous keys every time, minus does not need the shift key), more difficult to split (automatic analysis, editor functions) and introduces new possible complexity about how and when a character will be uppercased or not (capitalisation, abbreviations in identifiers)
• regarding typing effort: an identifier has usually at most one to two delimiters, which may be 10 percent of all characters. but the difference makes no practical difference. code is much more often read than written, and writing is easier, faster and more correct if it can be checked with less effort while writing
• separate words should use a delimiter. words are harder to read when there is no visible separation, where the delimiter is basically the empty-string
• negative example: r6rs introduced a new, competing naming scheme. for example with the flonum procedures that all use a "fl" prefix. the actual name of the procedure is significantly harder to discern - reading through the binding name listings, looking for procedures of interest, it is more difficult to discern the parts of the word and mask out the "fl" from flatan, flodd? flfinite? fl/ flabs and so on, to get the needed information. i am sure the inventor finds enough reasons for himself not to agree and to believe that this is optimal. could the type have been called float? so that it would be float-zero? float-odd? - it is a data type like others. could procedures have been named fl-atan fl-odd? fl-finite? or flo-atan flo-odd? flo-finite?

• for "to"
• for mapping/transformation/conversion/dictionaries or similar. {data-type}->{data-type}
• parameters: a procedure that does a conversion should not repeat its source-argument data-type in the variable-name and should use an unspecific identifier
• example: number->string :: a
• example with redundant information: number->string :: number
• variable names can create semantic dependencies to the type for example and this should be avoided where practical
• to group by prefix differently: {data-type}-from-{data-type}

• alternative, or
• example: port/path

• call-with-output-file
• integer-and-fraction
• false-if-exception
• first-or-false

• for procedures that evaluate to booleans (asking a question)
• examples: list? equal? contains?
• is- prefix for self-evaluating variables (the question is already answered)

• enumerations of similar variables
• example: index-1 index-2 index-3
• for short names this seems better: x1 x2 x3

for destructive or otherwise side-effecting procedures where the warning character of it might make sense

• for procedures that take an extra predicate procedure
• the rnrs procedures "remove" and "removep", where "remove" ist more general, are an example
• suffixing the "p" without minus may lead to weird words

• for bindings explicitly marked as syntax.
• for example syntax/macro alternatives to a procedure

• word abbreviations built by shortening the length of words, without removing inbetween characters
• the long words are then easier to guess. more arbitrary abbreviations can be confusing in that they are much more like new unrelated words that have to be learnt as such, or because they are ambiguous and could mean multiple things, and make many different variations by different authors possible
• an alternative is shortening combined with vowel removal, especially for words that start with a consonant

examples

• "abbrev" instead of "abvtn" for the word "abbreviation"
• "ele" instead of "elmt" for the word "element"

• one-letter identifiers only if it is easy to figure out, almost obvious, what they mean. one possible rule is that the place where they are introduced should be in sight.
• eventually not using them if words used instead save documentation
• not more than a limited amount of one-letter variables in one scope, maybe 4 or so. otherwise there is too much lookup required from the reader