7
$\begingroup$

Most languages have rules for identifiers similar to the following:

  • Must start with a letter or underscore
  • All characters after the first can be a letter, number, or underscore

Many languages add additional allowed characters to this. JavaScript allows $ at the start or otherwise, and Haskell allows ' anywhere after the first character, as two examples. Some languages, such as Scala, allow identifiers to be wrapped in something like a backtick, and include any characters, even spaces: `string to output`, for example.

What are the pros and cons for more permissive identifier rules?

$\endgroup$
6
  • $\begingroup$ I thought C also permitted $? $\endgroup$
    – Bbrk24
    Commented May 17, 2023 at 15:22
  • 2
    $\begingroup$ Are you includin unicode in your question? $\endgroup$
    – Adám
    Commented May 17, 2023 at 15:23
  • $\begingroup$ @Adám Umm...maybe. I think some separate questions for how to handle Unicode in identifiers would be better tho $\endgroup$
    – rydwolf
    Commented May 17, 2023 at 15:27
  • $\begingroup$ Btw, the C rules way precede C since they are present already in APL. $\endgroup$
    – Adám
    Commented May 17, 2023 at 15:29
  • $\begingroup$ @Bbrk24 I think I'll remove the "derived from C" part since those identifier rules are kinda everywhere, not specific to any paradigm/ancestry $\endgroup$
    – rydwolf
    Commented May 17, 2023 at 15:34

2 Answers 2

Reset to default
7
$\begingroup$

Pros

  • Symbols can express something much shorter than letters or numbers. I recall some JavaScript code style which used to prefix all jQuery collection variables (e.g. the result of $("div")) with $; Percentage is much longer to write than %, and Prime than ' (credits to @MichaelHomer)

Cons

  • Parsing can be harder, especially if you don't require whitespace between operators and identifiers. E.g. if you allow hyphens, is projected-cost an identifier or the result of a subtraction of two identifiers?
  • If you allow too many symbols, the code will become less readable by humans (though syntax highlighting helps a lot)
$\endgroup$
4
  • $\begingroup$ Regarding parsing, Factor just goes all in on permissive identifiers. [ on its own is normally a parsing word which starts a quotation (basically an anonymous function). But [a,b] is a completely valid function name which is defined in the standard library. $\endgroup$
    – Silvio Mayolo
    Commented May 17, 2023 at 16:02
  • 3
    $\begingroup$ Hyphens in identifiers isn't ambiguous if you require spaces around binary operators. Which is good practice anyway. $\endgroup$
    – ximo
    Commented May 17, 2023 at 21:46
  • $\begingroup$ @ximo: Indeed. COBOL code extensively uses - in identifiers. $\endgroup$
    – dan04
    Commented Jul 13, 2023 at 20:31
  • $\begingroup$ Not just good old COBOL, but also Forth. Not to mention the whole Lisp family (from LISP 1 to Clojure). And, of course, Raku. $\endgroup$
    – ximo
    Commented Dec 8, 2023 at 21:33
1
$\begingroup$

If a language limits identifiers to printable (non-blank) ASCII characters, then each identifier will have a unique visual representation in any font designed to be suitable for programming tasks, and will reliably survive most forms of translation between different character encodings.

It may be useful for a language to specify alternative visual representations for identifiers formed of ASCII characters, and recommend that editors allow programmers to select whether they wish to show identifiers as specified in ASCII, or using the alternative representations. A language could not be reasonably expected to forbid all forms of homohlyphs (representations that are visually indistinguishable), but if the "official" identifiers are written using ASCII, any ambiguous code could be made unambiguous by suppressing the display of alternative representations.

$\endgroup$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .