A language that I use (M) has this nifty feature that allows you to abbreviate most keywords to a single letter. For instance, the following code:

  new x
  for x=1:1:5 do
  . write !,x

is equivalent to this code:

  n x
  f x=1:1:5 d
  . w !,x

Most languages that I'm aware of this do not allow this. You have to spell "if" as "if" every time. What are the pros and cons of allowing users the choice of writing keywords "the long way" or abbreviating them?

  • 2
    $\begingroup$ Atari BASIC did something similar, but the abbreviations were an editing shortcut, and didn't affect the in-memory tokenized code format. You could type G.50, but LISTing the program expanded it to GOTO 50. $\endgroup$
    – dan04
    Commented Jul 4, 2023 at 1:34
  • $\begingroup$ Do you intend that your keywords are case-sensitive? Can an abbreviation be to any substring or only to the designated first or first few characters? I worked on a generalised SCPI parser a few months ago which resulted in a lot of "fun" caused by the standards apparent ignoring of some of the consequences of case/length issues. $\endgroup$ Commented Jul 4, 2023 at 9:47
  • $\begingroup$ Spectrum BASIC did it both ways: every keyword was (in the early versions at least) a keyboard key or chord, though you COULD type them out manually. However you entered them, each keyword was stored in a single byte in memory. Sort of like a simplified version of today's bytecode compilation. $\endgroup$ Commented Jul 4, 2023 at 18:41
  • 2
    $\begingroup$ In the time I type n, I can just as well type new. The same goes for f/for, i/if, etc. These short keywords are memorized patterns of keystrokes to my brain, and no more effort to type than any single letter/symbol. I think the word, and it appears right in front of my eyes. It is plain amazing how fast you can get at typing oft-repeated words, even when they are much longer. So, I'd say that anyone who feels the need for such abbreviations should consider some touch type training instead. $\endgroup$ Commented Jul 5, 2023 at 14:12
  • $\begingroup$ In C, you could #define i if and #define f for. $\endgroup$
    – CPlus
    Commented Jul 7, 2023 at 23:16

8 Answers 8


Pro: Code Golf

Most modern golfing languages have their common tokens as a single byte, if that. This is a very niche use case, but a use case nonetheless.

Con: Readability

Depending on how familiar you are with the language, it may not be obvious what each letter stands for.

Con: Ambiguity

From the perspective of the language designer, you have to be careful that each keyword starts with a distinct letter, or else these abbreviations could be ambiguous.

  • 9
    $\begingroup$ The ambiguity point is huge from a diachronic perspective--even if you get all the keywords lined up nice for abbreviations in the first version, what if you want to add more? And then, what happens to old abbreviated code? $\endgroup$ Commented Jul 4, 2023 at 9:04
  • 8
    $\begingroup$ Another way that abbreviations reduce readability: the more ways there are to express a construct, the more effort it takes to read. (When every loop looks the same, you can recognise it at a glance; but when every loop looks different, the more time and brainpower it takes to identify.) $\endgroup$
    – gidds
    Commented Jul 4, 2023 at 10:54
  • 1
    $\begingroup$ @UnrelatedString In part that can be handled by limiting abbreviations. (For example, you can abbreviate "while" down to "w", but require that "wait" be at least "wa".) Or contextual clues (e.g. "while" is attached to a sub-block, while "wait" is not). -- Of course, this is just a different type of ambiguity, pushed onto the programmer & reader. $\endgroup$
    – R.M.
    Commented Jul 4, 2023 at 14:48

You don't need to explicitly allow this, because it is a feature that could easily be implemented on the level of the development environment if it is desired. Programmers could configure their editor to automatically display for as f , and substitute f with for when entered.

  • 1
    $\begingroup$ This is in fact one advantage of projectional editing. $\endgroup$
    – Polygnome
    Commented Jul 5, 2023 at 13:43

How do you differentiate identifiers from keywords?

This can be a con, depending on how you have your language. Consider an if-expression:

x=if cond do

How will you differentiate a variable called i and an if expression?

x=i cond d foo(); e bar(); fi
  • 7
    $\begingroup$ +1. Specifically, the parser doesn't know whether i is a keyword or an identifier until it looks further ahead. Essentially, it makes most of the language's keywords into contextual keywords, except that parsers for most languages with contextual keywords can determine keywordness from already-known context, without requiring lookahead in the parser. $\endgroup$
    – kaya3
    Commented Jul 4, 2023 at 2:08
  • $\begingroup$ @kaya3-supportthestrike: Does it, though? I mean, the obvious "fix" is to treat any prefix of a keyword as a keyword, immediately forbidding variables of that spelling. Not sure I'd want to code in such a language, but the parser would remain straightforward. $\endgroup$ Commented Jul 5, 2023 at 12:20

I'll disagree with all the positive comments and say that there is no serious benefit at all. Your line of code might be 6 characters shorter and far less readable. If you are using descriptive variable names (like you should), you will sacrifice maybe 60 characters in a line to fit 3 variables. Character count in a line is not a big issue ever since monitors replaced terminals and as the screens became bigger, it became even less of an issue.

Linux kernel developers would sacrifice 8 characters just for the indentation to discourage nesting - that is more space wasted than you save in the for statement you gave as an example. When you need to sacrifice either readability or 80 character width limit, I don't see a situation in which you would ever choose to sacrifice readability.


Programming languages are optimized for their specific use case. There are a few programming languages that try to be as dense as possible. These are mainly languages intended for code golf, where length comes as a premium and it is of utmost importance to actually save every last bite.

But, this comes at a steep penalty to readability.

There is an old adage for programmers, which is "Code is more often read than written" (attributed sometimes to Raymond Chen or Guido van Rossum, inventor of Python).

It doesn't really matter for the compiler if the keywords are short or not. Typical code-bases do not grow so large that it makes an appreciable difference. Assets (images, audio, video etc.) will typically exceed the size of the code-base by many, many magnitudes. And once interpreted or compiled, it doesn't matter anymore, anyways.

So for the execution of the program, it does not matter. What matters is when humans interact with the text. But programs are not written linearly, and usually done supported with an IDE which will offer code completion anyways.

Developers spend most time thinking about the code and finding solutions. The time to actually type the program is only small fraction of the work that goes into developing it.

But code is quite often read to gain understanding. Old parts of the codebase, code examples in tutorials, code written a few days ago, code written years ago. We read code all the time.

That is why most languages focus on readability. Because that is what we mostly do with the code as humans, what we spent the most time doing, and what needs to be as easy as possible for most mainstream, general purpose languages.

Unless you are in a niche field like a golfing language, optimizing for readability will be a core concern. And readable keywords, not cryptic one-letter combinations, are a big part of that.


As someone who uses a language like this almost every day and where the norm is to use single letters for keywords, one of the pros is that it really helps with line length. While 1-3 characters may not seem like a lot, it does add up, and in a language where you can't extend lines to the next line, it really helps with cutting out noise.

For instance, in this language, it's "idiomatic" to write loops that traverse an array in the following manner:

  f  s index=$O(myArray(index)) q:index="" d
  . ; Insert body of loop

Compare this with the version with the keywords written out:

  for  set index=$ORDER(myArray(index)) quit:index="" do
  . ; Insert body of loop

Some loops might have more complicated ending conditions, and while it's sometimes feasible to move it inside the loop body, it generally requires an extra "done" variable or similar to do, so it's nicer to do it on one line.

Now, some of you may be thinking, "Isn't it harder to read the one-letter version?" It is, but only when you are first learning the language. Over time, you get used to the one-letter version until it becomes as natural as the other version. In fact, I can read the one-letter variant more easily than the version with the long form keywords.

  • 4
    $\begingroup$ Tastes vary, but to me both versions are horrible. Why would a for construct need four separate keywords in the first place? That's excessive and of very dubious merit. The only reason why such a high keyword density could be benefitial is to ease readability to people unfamiliar with the language, but that goes completely out of the window if you then shorten them away. $\endgroup$ Commented Jul 4, 2023 at 17:05

Furcadia's DragonSpeak (aka "DS": https://cms.furcadia.com/creations/dreammaking/dragonspeak/dragonspeak-reference#parser) was one fun language I've used where something similar was used by advanced coders. Not exactly the same, but the principle of brevity holds, and it shows some possible advantages.

DS lines look like:

# Dance pole crowd responses.
(0:4) When someone turns,
 (1:36) and they are male,
 (1:29) and they are a Squirrel,
      (5:200) emit message {Show us your nuts!} to the triggering furre.

Each line is added with a click in the editor, rather than by writing a keyword, and lines are stacked to create complex if/where/and/or clauses and their effects.

But this can become very verbose to read.

And in fact (as the link above says) you can modify the text of the commands: all that matters to the parser for any line is the numbers, and any strings in {curlies}. So just as in a language where commands are single keywords, the command "WhenSomeoneTurns" might have the abbreviated form "Wst", so in DS, you can abbreviate the command "(0:4) When someone turns," down to just "(0:4)".

So if you have written a block, and now want a large number of similar blocks, you can do something like:

# Dance pole crowd responses to male scuirine dancer.
(0:4) When someone turns,
 (1:19) and they are standing at position (68,70)
 (1:36) and they are male,
 (1:29) and they are a Squirrel,
      (5:200) emit message {Show us your nuts!} to the triggering furre.

# Variations (abbreviated versions of the above)
(0:4)(1:19)68,70(1:37)Female(1:29)Squirl(5:200){Show us that tail!}
(0:4)(1:19)68,70(1:38)Unspec(1:29)Squirl(5:200){Work it, squirl!}
(0:4)(1:19)68,70(1:36)Male  (1:23)Canine(5:200){Go, hound dawg!}
(0:4)(1:19)68,70(1:37)Female(1:24)Canine(5:200){Shake it, biyatch!}
(0:4)(1:19)68,70(1:38)Unspec(1:23)Canine(5:200){Wag that tail!}
(0:4)(1:19)68,70      Any   (1:26)Dragon(5:200){Flame out!}

The variations need only a word or so to call out differences between them and the fully-annotated block.

Because the blocks are now written as oneliners, adjacent and aligned, we can see at a glance how they differ. It's clear even to someone unfamiliar with the language that they all relate to the same coordinate (68,70: likely containing the dance pole), and that this is a list of lines displaying text depending on the gender and species of the pole's dancer.

By allowing this adjacent alignment, the abbreviation makes the code easier to read, and typos easier to spot. The above code has one typo, which you MIGHT have spotted because of this arrangement, but would have been essentially invisible to even experienced DS coders with the code expanded. (Spoiler, reversed: rebmun seiceps s'eninac dnoces ehT)

In code with several thousand lines this can also make a huge difference to sharability. In fact, the first DS code I shared in a forum post, using an early and limited version of DS (http://forums.furcadia.com/200) was 1169 commands, but was reduced down to 334 lines (273 of code, plus whitespace and comments).

Something similar could be done with a language that permits single-character commands. The downside is that variable names would then also have to be short.

It should be immediately obvious that there many MUCH BETTER WAYS to reduce this repetition in any normal programming language. Methods, functions, loops, etc.

Encouraging brevity just so that people can have easily-debugged code repetition feels to me like an antipattern: it encourages the type of repetition I show above, AND it discourages readable-length variable names because they would harm the brevity.

Other than deliberate code golfing, the only exception I can think of where such brevity is useful is the very specific case of a programming language like DS, which deliberately avoids any form of looping to avoid the possibility of shooting oneself in the foot with infinite loops.

  • 1
    $\begingroup$ I'm trying to understand this language as much as I can from the link you provided, apologies if I'm getting something wrong. Are you saying that you can omit "and they are" and such, because the parser will understand the instructions without them? If so, then I wouldn't agree it's at all similar to what the OP is describing, those structures in Dragonspeak act more like optional comments, not keywords. $\endgroup$ Commented Jul 4, 2023 at 20:30
  • $\begingroup$ @ReverentLapwing Yes, all text is merely syntactic sugar for humans, ignored by the parser. Only the numbers (and in later versions of the language which supported them {strings in curlies} and @variables) are parsed. The rest can be removed to reduce the pain of repetition. In a similar way, a language could allow most text of keywords to be collapsed for brevity, but that only helps if variable and method names are similarly terse. So I'm very far from convinced it'd be an advantage in non-golfing languages with loops, variables, classes, etc. $\endgroup$ Commented Jul 4, 2023 at 20:42

One pro is that it saves space, which is helpful for code-golfers and may help with readability in the case of long variable names (think resulting-weather-data-analysis-dataframe) or long lines of code. In these cases, having abbreviations for well-known operations (such as print) may save a lot of time for the programmer.

However, there are a few cons to this approach. There aren't an infinite number of letters in the alphabet, so ambiguity will be a problem with abbreviations - it may be hard to choose unique identifiers. In addition, new users may not understand what the letters stand for or have knowledge of the common abbreviations for operations.

  • $\begingroup$ Given abbreviations are limited to keywords, they won't help with long variable names. $\endgroup$ Commented Jul 5, 2023 at 12:22

You must log in to answer this question.

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