<p>Most languages have rules for identifiers similar to the following:</p>
<ul>
<li>Must start with a letter or underscore</li>
<li>All characters after the first can be a letter, number, or underscore</li>
</ul>
<p>Many languages add additional allowed characters to this. JavaScript allows <code>$</code> at the start or otherwise, and Haskell allows <code>'</code> 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: <code>`string to output`</code>, for example.</p>
<p>What are the pros and cons for more permissive identifier rules?</p>

<syntax><identifiers>
What are the pros and cons of more permissive identifier character sets?
CC BY-SA 4.0
2023-05-17T21:49:07.450Z
JavaScript is _very_ permissive in its allowed identifiers.

https://mothereff.in/js-variables#%E0%B2%A0%5f%E0%B2%A0
ximo
CC BY-SA 4.0
2023-05-17T15:22:18.670Z
I thought C also permitted `$`?
Bbrk24
CC BY-SA 4.0
2023-05-17T15:23:49.327Z
Are you includin [tag:unicode] in your question?
Adám
CC BY-SA 4.0
2023-05-17T15:27:52.170Z
@Adám Umm...maybe. I think some separate questions for how to handle Unicode in identifiers would be better tho
rydwolf
CC BY-SA 4.0
2023-05-17T15:29:03.307Z
Btw, the C rules way precede C since they are present already in APL.
Adám
CC BY-SA 4.0
2023-05-17T15:34:47.690Z
@Bbrk24 I think I'll remove the "derived from C" part since those identifier rules are kinda everywhere, not specific to any paradigm/ancestry
rydwolf
<h3>Pros</h3>
<ul>
<li>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 <code>$(&quot;div&quot;)</code>) with <code>$</code>; <code>Percentage</code> is much longer to write than <code>%</code>, and <code>Prime</code> than <code>'</code> (credits to <a href="https://languagedesign.stackexchange.com/a/439/26">@MichaelHomer</a>)</li>
</ul>
<h3>Cons</h3>
<ul>
<li>Parsing can be harder, especially if you don't require whitespace between operators and identifiers. E.g. if you allow hyphens, is <code>projected-cost</code> an identifier or the result of a subtraction of two identifiers?</li>
<li>If you allow too many symbols, the code will become less readable by humans (though syntax highlighting helps a lot)</li>
</ul>

CC BY-SA 4.0
2023-05-17T16:00:23.710Z
2023-05-18T13:09:02.117Z
2023-05-18T13:09:02.117Z
Glorfindel
CC BY-SA 4.0
2023-12-08T21:33:29.623Z
Not just good old COBOL, but also Forth. Not to mention the whole Lisp family (from LISP 1 to Clojure). And, of course, Raku.
ximo
CC BY-SA 4.0
2023-05-17T21:46:14.570Z
Hyphens in identifiers isn't ambiguous if you require spaces around binary operators. Which is good practice anyway.
ximo
CC BY-SA 4.0
2023-07-13T20:31:53.937Z
@ximo: Indeed.  COBOL code extensively uses `-` in identifiers.
dan04
CC BY-SA 4.0
2023-05-17T16:02:45.937Z
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.
Silvio Mayolo
<p>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.</p>
<p>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 &quot;official&quot; identifiers are written using ASCII, any ambiguous code could be made unambiguous by suppressing the display of alternative representations.</p>

CC BY-SA 4.0
2023-07-13T18:16:00.940Z
2023-07-13T18:16:00.940Z
supercat
# What are the pros and cons of more permissive identifier character sets?
Posted by: username_0 on 2023-05-17
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?
**Tags:** syntax identifiers
> **Comments:**
> **username_2**: I thought C also permitted `$`?  
> **username_3**: Are you includin [tag:unicode] in your question?  
> **username_0**: @Adám Umm...maybe. I think some separate questions for how to handle Unicode in identifiers would be better tho  
> **username_3**: Btw, the C rules way precede C since they are present already in APL.  
> **username_0**: @Bbrk24 I think I'll remove the "derived from C" part since those identifier rules are kinda everywhere, not specific to any paradigm/ancestry  
> **username_1**: JavaScript is _very_ permissive in its allowed identifiers.

https://mothereff.in/js-variables#%E0%B2%A0%5f%E0%B2%A0  
---
## 2 answers
### Answer by username_4 on 2023-05-17. Score: 7
### 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](https://languagedesign.stackexchange.com/a/439/26))

### 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)
> **Comments:**
> **username_6** (2023-05-17): 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.  
> **username_1** (2023-05-17): Hyphens in identifiers isn't ambiguous if you require spaces around binary operators. Which is good practice anyway.  
> **username_5** (2023-07-13): @ximo: Indeed.  COBOL code extensively uses `-` in identifiers.  
> **username_1** (2023-12-08): Not just good old COBOL, but also Forth. Not to mention the whole Lisp family (from LISP 1 to Clojure). And, of course, Raku.  
---
### Answer by username_7 on 2023-07-13. Score: 1
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.
---
