ET: Lexical Conventions and Style Rules

Eiffel software texts are free-format: distribution into lines is not semantically significant, and any number of successive space and line-return characters is equivalent to just one space. The style rules suggest indenting software texts as illustrated by the examples in this chapter.

Successive declarations or instructions may be separated by semicolons. Eiffel's syntax has been so designed, however, that (except in rare cases) the semicolon is optional. Omitting semicolons for elements appearing on separate lines lightens text and is the recommended practice since semicolons, as used by most programming languages, just obscure the text by distracting attention from the actual contents. Do use semicolons if you occasionally include successive elements on a single line.

56 names -- all unabbreviated single English words, except for elseif which is made of two words -- are reserved, meaning that you cannot use them to declare new entities. Here is the list:

agent alias all and as assign check
class convert create Current debug deferred do
else elseif end ensure expanded export external
False feature from frozen if implies indexing
infix inherit inspect invariant is like local
loop not obsolete old once or prefix
Precursor pure redefine reference rename require rescue
Result retry separate then True TUPLE undefine

note: infix, prefix are not anymore reserved since version 19.12 , and indexing as well even before.

Since this tutorial has covered all the essential mechanisms, you may ignore the keywords not encountered; they are reserved for future use.

Most of the reserved words are keywords, serving only as syntactic markers, and written in boldface in typeset texts such as the present one: class, feature, inherit. The others, such as Current, directly carry a semantic denotation; they start with an upper-case letter and are typeset in boldface.

These conventions about letter case are only style rules. Eiffel is case-insensitive, since it is foolish to assume that two identifiers denote two different things just on the basis of a letter written in lower or upper case. The obvious exception is manifest character constants (appearing in single quotes, such as 'A') and manifest character strings (appearing in double quotes, such as "UPPER and lower").

The style rules, however, are precise, and any serious Eiffel project will enforce them; the tools of EiffelStudio also observe them in the texts they output (although they will not mess up with your source text unless you ask them to reformat it). Here are the conventions, illustrated by the examples of this tutorial:

  • Class names in upper case, as ACCOUNT.
  • Non-constant feature names and keywords in lower case, as balance and class.
  • Constant features and predefined entities and expressions with an initial upper case, as Avogadro and Result.

In typeset documents including Eiffel texts, the standard for font styles is also precise. You should use bold face for keywords and italics for all other Eiffel elements. Comments, however, are typeset in roman. This lets a software element, such as an identifier, stand out clearly in what is otherwise a comment text expressed in English or another human language, as in the earlier example -- Add `sum' to account.

which makes clear that sum is a software element, not the English word.

There is also an Eiffel style to the choice of identifiers. For features, stay away from abbreviations and use full words. In multi-word identifiers, separate the constituents by underscores, as in LINKED_LIST and set_owner. The competing style of no separation but mid-identifier upper-case, as in linkedList or setOwner, is less readable and not in line with standard Eiffel practices.

Features of reusable classes should use consistent names. A set of standard names -- put for the basic command to add or replace an element, count for the query that returns the number of element in a structure, item to access an element -- is part of the style rules, and used systematically in EiffelBase. Use them in your classes too.

For local entities and formal arguments of routines, it is all right to use abbreviated names, since these identifiers only have a local scope, and choosing a loud name would give them too much pretense, leading to potential conflicts with features.

The complete set of style rules applied by ISE is available on the web in both HTML and PDF forms. These rules are an integral part of the Eiffel method; in quality software, there is no such thing as a detail. Applying them systematically promotes consistency between projects in the Eiffel world, enhances reusability, and facilitates everyone's work.