| • Science | • People | • Locations | • Timeline |
| Contents | ||
Created in 1985, Eiffel is a mature OO language with development systems available from multiple suppliers. Despite this maturity and a generally excellent reputation among those who are familiar with the language, Eiffel has failed to gain much interest from software developers. The reasons for this lack of interest are unclear, and are a topic of frequent discussion within the Eiffel community.
Distinguishing characteristics of Eiffel include Design by contract (DbC), liberal use of implementation inheritance including multiple inheritance, value types implemented via value semantics, and generic classes. Eiffel has a unified type system— all types in Eiffel are classes, so it is possible to create subclasses of the basic classes such as INTEGER.
Eiffel has operator overloading, including the ability to define new operators, but does not have method overloading.
The Eiffel language aims to promote clear and elegant coding. Eiffel emphasizes declarative statements over procedural code, and eliminates the need for bookkeeping instructions.
Eiffel intentionally limits stylistic expression, providing few means for clever coding tricks or coding techniques intended as optimization hints to the compiler. Some software developers feel constrained by Eiffel's simplicity, sometimes to the extent of describing Eiffel programming as "bondage and discipline".
In contrast, others feel that the simplicity of the language not only makes the code more readable, but also allows a programmer to concentrate on the important aspects of a program without getting bogged down in implementation details. Eiffel's simplicity is intended to promote simple, readable, usable, reusable, reliable and correct answers to business problems. Eiffel seeks to produce a quality software system over anything else.
Eiffel is not case-sensitive. Both keywords and identifiers can be written in any combination of upper and lower case. The tokens MaKe and make and MAKE all refer to the same identifier. Coding style standards, however, generally prescribe the use of all-capitals for class names, all lower-case for variables and method names, and initial capitals for constants, with underscores separating words.
Eiffel's syntax can be parsed without requiring end-of-statement markers. The use of semicolons as statement terminators or as statement separators is left to the discretion of the programmer. Putting a semicolon in or leaving one out makes no difference, except in the unusual case of a statement starting with a left parenthesis. Most Eiffel programmers choose to omit semicolons except when putting multiple statements on a line.
Eiffel requires that sections and clauses appear in a specific order.
In contrast to most members of the curly brace family of programming languages, Eiffel does not permit expressions to be used as statements, nor statements to be used as expressions. Accordingly, a method which returns a value can only be used in expressions, while a method which does not return a value can only be invoked by method call statements.
This philosophy—that expressions and statements are fundamentally different in nature—is expanded into the concept of Command-Query Separation (CQS). Under CQS, a query method (a function which returns a value) must not change the state of the object, while a command method will change the state of the object but will not return a value. CQS is strongly recommended for Eiffel programming, but is not actually enforced by the Eiffel system.
Unlike most programming languages, Eiffel is not normally displayed in a monospaced typeface. The recommended display style is to use a proportional typeface. Keywords are shown in bold, user-defined identifiers and constants are shown in italics. Standard upright (roman) style is used for comments, operators, and punctuation marks.