Eiffel Home Page (Web) -- Getting started with Eiffel (local)

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

63 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

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 " lower and UPPER " ).

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 boldface 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 langage, 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.

Eiffel Home Page (Web) -- Getting started with Eiffel (local)