How permissive should a language be about identifiers?

Question

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.}

Answer 1

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.

Answer 2

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.

Answer 3

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

Answer 4

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.

Answer 5

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.

Answer 6

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.