[[Property:modification_date|Wed, 01 Jul 2020 08:44:12 GMT]]
[[Property:publication_date|Wed, 01 Jul 2020 08:44:12 GMT]]
[[Property:title|ET: Lexical Conventions and Style Rules]]
[[Property:weight|-2]]
[[Property:uuid|60fdf029-8626-166d-cc4f-9069aacdda7f]]
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 <code>elseif</code> which is made of two words -- are reserved, meaning that you cannot use them to declare new entities. Here is the list: 


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

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: <code>class</code>, <code>feature</code>, <code>inherit</code>. The others, such as <code>Current</code>, 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 <code>'A'</code>) and manifest character strings (appearing in double quotes, such as <code>"UPPER and lower"</code>). 

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 <code>ACCOUNT</code>. 
* Non-constant feature names and keywords in lower case, as <code>balance</code> and <code>class</code>. 
* Constant features and predefined entities and expressions with an initial upper case, as <code>Avogadro</code> and <code>Result</code>. 

In typeset documents including Eiffel texts, the standard for font styles is also precise. You should use <code>bold face</code> for keywords and <code>italics</code> for all other Eiffel elements. Comments, however, are typeset in <code>roman</code>. 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 
<code>
            -- Add `sum' to account.
</code>

which makes clear that <code>sum</code> 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 <code>LINKED_LIST</code> and <code>set_owner</code>. The competing style of no separation but mid-identifier upper-case, as in <code>linkedList</code> or <code>setOwner</code>, is less readable and not in line with standard Eiffel practices. 

Features of reusable classes should use consistent names. A set of standard names -- <code>put</code> for the basic command to add or replace an element, <code>count</code> for the query that returns the number of element in a structure, <code>item</code> 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 <span> [http://archive.eiffel.com/doc/manuals/language/style/page.html HTML]  </span> and <span> [http://archive.eiffel.com/doc/manuals/language/style/style.pdf PDF]  </span> 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.