Eiffel Programming/Unfeatures

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

Goto, break or the equivalent

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

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

CamelCase

Underscore_notation_is_preferred_for_better_readability
Vs.
CamelCaseNotationWhichCanBeSeemsSmart

Case sensitivity

    True = true = TRUE

Overloaded Names

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.