In case a suitable notation does not already exist, the new language should be adopted as close as possible to other existing notations within the domain or to other common used languages. A good example for commonly accepted languages are mathematical notations like arithmetical ex- pressions [8].

Guideline 15: “Use descriptive notations.” A descriptive notation supports both learnability and comprehensibility of a language especially when reusing frequently-used terms and symbols of domain or general knowledge. To avoid mis- interpretation it is highly important to maintain the seman- tics of these reused elements. For instance, the sign “+” usually stands for addition or at least something seman- tically similar to that whereas commas or semicolons are interpreted as separators. This applies to keywords with a widely-accepted meaning as well. Furthermore, keywords should be easily identifiable. It is helpful to restrict the num- ber of keywords to a few memorizable ones and of course, to have a keyword-sensitive editor.

A good example for a descriptive notation is the way how special character like Greek letters are expressed in Latex. Instead of using a Unicode-notation each letter can be ex- pressed by its name (alpha for α, beta for β, and so on).

Guideline 16: “Make elements distinguishable.” Easily dis- tinguishable representations of language elements are a ba- sic requirement to support understandability. In graphical DSLs, different model elements should have representations that exhibit enough syntactic differences to be easily dis- tinguishable. Different colors as the only criteria may be counterproductive, e.g., when printed in black and white. In textual languages usually keywords are used in order to sep- arate kinds of elements. These keywords have to be placed in appropriate positions of the concrete syntax, as other- wise readers need to start backtracking when “parsing” the text [8, 22]. The absence of keywords is often based on effi- ciency for the writer. But this is a very weak reason because models are much more often read than written and therefore to be designed from a readers point of view.

Guideline 17: “Use syntactic sugar appropriately.” Lan- guages typically offer syntactic sugar, i.e., elements which do not contribute to the expressiveness of the language. Syn- tactic sugar mainly serves to improve readability, but to some extent also helps the parser to parse effectively. Key- words chosen wisely help to make text readable. Generally, if an efficient parser cannot be implemented, the language is probably also hard to understand for human readers.