This is a sister question to: Is it bad to use Unicode characters in variable names?

As is my wont, I'm working on a language project. The thought came to me that allowing multi-token identifiers might improve both readability and writability:

primary controller = new Data Interaction Controller();

# vs.

primary_controller = new DataInteractionController();

And whether or not you think that's a good idea*, it got me musing about how permissive a language ought to be about identifiers, and how much value there is in being so.

It's obvious that allowing characters outside the usual [0-9A-Za-z_] has some advantages in terms of writability, readability, and proximity to the domain, but also that it can create maintenance nightmares. There seems to be a consensus (or at least a trend) that English is the language of programming. Does a Chinese programmer really need to be writing 电子邮件地址 when email_address is the international preference?

I hate to be Anglocentric when it comes to Unicode, or a stickler when it comes to other identifier restrictions, but is it really worth it to allow crazy variable names?

tl;dr: Is the cost of laxity higher than the potential benefit?

Why or why not? What experiences and evidence can you share in favour of or opposed to relaxed restrictions? Where do you think is the ideal on the continuum?

* My argument in favour of allowing multi-token identifiers is that it introduces more sane points to break long lines of code, while still allowing names to be descriptive, and avoiding ExcessiveCamelCase and a_whole_lot_of_underscores, both of which are detrimental to readability.

  • 1
    Dear close-voter: I've done my best to improve the question; in the future please explain your close-vote and offer some pointers for improvement.
    – Jon Purdy
    May 1, 2011 at 16:28
  • One language that is very permissive is Agda. It allows anything except Unicode whitespace and a handful of reserved operators. Dec 1, 2012 at 1:24
  • I wish programming languages would require that every use of an identifier match the declaration precisely, but also forbid the use of identifiers which differ only in case, accents, etc. Such a rule would IMHO combine the advantages of both case-sensitive and non-case-sensitive languages, but I don't know any language that works that way.
    – supercat
    Jan 28, 2014 at 22:11

6 Answers 6


That's rather hard to say. More permissive grammars are more difficult to parse. Ruby's optional parentheses are a good example of this. The lack of extant languages with this feature may not prove that it's a bad idea, but it doesn't help validate it either. There isn't much else to go on.

If you think it's a good idea and it's relatively easy to execute, why not go ahead and do it? That's the only real way to get a definitive answer to questions like this.

  • 1
    I like this stance. "If you don't know if it works, test it and see."
    – Jon Purdy
    May 1, 2011 at 1:43
  • 2
    Otherwise there would never be any innovation. May 1, 2011 at 1:46
  • 1
    @Jon Purdy: On the other hand, this approach did occur a few times in the distant past and was quickly dumped. I think it would be foreign to most developers and confuse them, if not the parser.
    – Orbling
    May 1, 2011 at 5:32
  • 1
    @Orbling: Sometimes confusing developers in the short run is actually worth it in the long run. And if it fits well with the rest of his language, it might not be very confusing at all. May 1, 2011 at 9:05
  • Taking a lesson from history means you are less likely to be doomed to repeat it. There were valid reasons for quickly dumping some esoteric language features, an looking at some languages, I doubt very much programmer confusion was a part of it.
    – mattnz
    Dec 3, 2012 at 0:08

I once worked with USL which allowed a space as part of a name. The combinatorial possibilities became a nightmare. Is "LAST LEFT TURN" one identifier? Or two ("LAST LEFT" and "TURN") or two identifiers ("LAST" and "LEFT TURN") or three? And is "RIGHT TURN" (one blank) the same as "RIGHT TURN" (two blanks) even though a text editor won't match them? No, don't ever accept blanks in names.

For similar reasons never accept special characters that mean something in the language. Is "ALPHA-BETA" a variable name or a subtraction?

Normally identifiers must start with a letter. Are you going to extend that to other Unicode languages? How will you know what a letter is in Arabic?

I fear that you are opening a gigantic can of worms.

  • 2
    1) I think we've been over this before: it's not combinatorial, it's exponential. 2) That problem doesn't come up in my project because two randomly adjacent identifiers don't mean anything; LAST LEFT TURN is always a single identifier. 3) Interpretation of otherwise-significant characters depends on your approach to lexing: many Lisps have very few identifier restrictions at the cost of a certain amount of required whitespace and parens. 4) Arabic is not a good example, but that's a good point; luckily Unicode is organised well, and it's possible to allow/exclude vast ranges quite sanely.
    – Jon Purdy
    May 1, 2011 at 0:52
  • Actually, come to re-read, I think your concepts of what constitutes an identifier, and of the state of lexing and parsing in general, are actually rather outdated. I'd retract my upvote, but you'd have to make a (possibly null) edit.
    – Jon Purdy
    May 1, 2011 at 1:48
  • 1
    I took a class that was done entirely in lisp, which allows alpha-beta as an identifier, and actually found it very reasonable. In fact, getting back to other languages was annoying afterwards. May 1, 2011 at 9:02
  • 2
    @Tikhon Jelvis: Yeah, the uniformity is very logical: - is an identifier just as alpha-beta is an identifier, and the lexer just relies on whitespace and parens to separate tokens. It's really quite elegant in its (almost naive) simplicity.
    – Jon Purdy
    May 1, 2011 at 16:35
  • @Jon Purdy: I'm still not sure how do you solve the ambiguity. Say your parser already has encountered that an identifier alpha, beta and alpha-beta exist. How do you separate alpha-beta from alpha - beta in say i = alpha-beta;?
    – n1ckp
    May 1, 2011 at 19:12

Some early programming languages did allowed spaces in identifiers; e.g. early FORTRAN (pre F77), some dialects / implementations of Algol, AppleScript, etc.

From a programming language perspective it is a bad idea because it introduces lots of ambiguity. Resolving that ambiguity is hard work for the compiler, and ultimately it makes the language more complicated and harder to read. For instance:

String str = "";

Is that declaring a variable called str, or assigning a value to a previously declared variable called "String str"?

Eliminating this kind of ambiguity (while allowing spaces in names) some other changes to the language syntax; e.g. requiring keywords to be quoted, requiring keywords to be all caps, eliminating all keywords from the language (!).

See also: https://stackoverflow.com/questions/1805030/why-programming-languages-do-not-include-spaces-in-the-method-identifiers

  • 2
    I think it has great potential to introduce ambiguity, yes. The only reason I'm considering it in my case is that the syntax of the language is such that there is neither any ambiguity nor any added complexity.
    – Jon Purdy
    May 1, 2011 at 0:57
  • 1
    @Jon Purdy - if you are designing your own language, and you can really eliminate the possibility of ambiguity by some means that is acceptable to users of your language ... go ahead.
    – Stephen C
    May 1, 2011 at 1:13
  • Hah, well, yes, that is the case. There was the choice of whether to allow reserved words within multi-token identifiers, but I think that's an easy no.
    – Jon Purdy
    May 1, 2011 at 1:24

From a parsing point of view, it looks like it could easily become hell to implement and maintain. Though it'd become quite reasonable if you introduce some notation to let the parser know when you're dealing with multi token idents, and parsing is then a non-issue.

As an example, F# allows almost anything to be used in an identifier, but you must surround the whole thing with pairs of grave accents, so it's valid to write

let ``primary controller`` = new ``Data Interaction Controller``();

Although the feature is there, it's rarely used by the programmer manually. There are various tools which dynamically generate code where these identifiers are useful, and that will be more apparent in F#3.0, which can literally take data from the web or elsewhere and allow it to be used as strongly typed identifiers, without first normalizing the data to fit into ASCII.

  • Isn't F# a .Net language? They all need such a feature, because they have to deal with names from other languages. They all have to accept class, Class, CLASS , ectera.
    – MSalters
    May 2, 2011 at 12:15
  • @MSalters: Not all .NET languages have this feature. C# doesn't for sure, and it cannot call types written in F# which have such identifiers. The CLR supports nearly any string as an identifier name, but only F# of the main languages supports it.
    – Mark H
    May 2, 2011 at 12:59
  • @sharpie: VB.Net, another main language, escapes identifiers with []. That seems to work the same.
    – MSalters
    May 2, 2011 at 13:24

I'm not sure about spaces but it must be possible. I do think it means you have to give up on spaces in other places, and that's a decision you should weigh. In curly-style languages spaces are usually only necessary for separating keywords from identifier and separating types from identifiers (int x, new Y).

Hmm. When I think about it, it might not even be as unfeasible as I thought.

For the UTF8-chars I'm feeling the same kind of ambivalence. Clearly the horrors of trying to type localized chars on a non-localized keyboard layout or having two chars that look alike but are not the same are a nightmare.

At the same time, the adagium 'program in English' simply can't be applied everywhere. It's great for abstract concepts and libs and such, but when you are programming business logic you may need to represent local concepts (I could think of legal terms), and it's only confusing to translate them to an English approximation and then back again. If you have a latin-scriptbased language you might get away with ditching the non-ascii-chars but the more you get away from that, the harder it gets. And the more the concepts you need might not have a good English translation too.

So I guess I have to leave this undecided. I do not need either spaces or utf8-chars at the moment though.


I've been wondering about this myself.

We've seen the "relax" attitude in the design of HTML, and having to work with it daily, I can only say it led to a mess. As a result I heartily support a well-specified approach... and one that rejects outright anything outside of the specs.

Once this is said and done, I prefer being pragmatic. You want me to read/work on/use your programs ? Then:

  • don't use characters that are not immediately accessible on my keyboard (basically, stick to what C uses itself), for the record, I alternate between Azerty (home) and Qwerty (work)
  • program in English

I suppose that if you use it only for yourself or share it only with like-minded fellows, then anything goes. But working in a multi-cultural environment (a bit of everything from Europe, as well as some from North Africa, India and China), uniformity is required, and English is well-suited. And before you think that I am lazy for wanting to impose my mother-tongue, I am French, so I had to learn English, and I am still.

Then comes the issue of blanks. I don't know about this. I can see a few issues with the use of Turn then Turn Left which would make it awkward to grep/sed if required, but nothing outstanding.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.