Eiffel Programming/Unfeatures

From Wikibooks, open books for an open world
< Eiffel Programming
Jump to: navigation, search

Eiffel Unfeatures — What you Won't See in the Language[edit]

Goto, break or the equivalent[edit]

Ever since the advent of structure programming the goto has been considered evil, yet many programming languages support it. Eiffel does not. The language is designed to uphold the principle of Single Entry/Single Exit.

Some people consider this a gross inefficiency and will labor endlessly to demonstrate arcane algorithms that are allegedly faster with a well-placed goto, or it requires fewer variables, or fewer lines of code. Others consider is a serious crimp to their writing style.

Yet there are two serious advantages to the principle of Single Entry/Single Exit. First, it encourages the programmer to think clearly about the implementation. In other languages, if you find yourself in getting into trouble deep inside a multiply nested loop, you bail out with a goto. In Eiffel, you have to rethink the structure of the code, often to the benefit of the final program.

Second, source code is read much more often than it is written. The absence of a goto statement makes it easier to grasp the implementation. There are no subtle tricks buried in the inner loop that can skip to some arbitrary location.

Globals[edit]

    State shared via the once statement
       Allows precise control over sharing data

CamelCase[edit]


Underscore_notation_is_preferred_for_better_readability
Vs.
CamelCaseNotationWhichCanBeVeryDifficultToRead

Case sensitivity[edit]

    True = true = TRUE

Overloaded Names[edit]

Overloaded names, also known as operator overloading, introduces ambiguity for the human programmer and reader of source code, and in some cases, for the compiler as well. Eiffel avoids this source of errors by not implementing it.