Eiffel The Language
Setting It All Up
Getting Started
Design and Documentation
Miscellaneous
- Old Site (login)
Eiffel The Language
Setting It All Up
Getting Started
Design and Documentation
Miscellaneous
Observer basic style rules such as:
For variable naming, the following has been suggested (by Larry Rix):
One may now read without ambiguity:
We can scroll the top of this routine up beyond the top of the editor where we can no longer see it and then start reading the routine from the bottom and NOT loose my capacity to understand each identifier scope and perhaps not even its semantic (of which scope is a part for identifiers like locals, attachment locals, and iteration cursor locals).
In a book or other writing, what is more laborious? To understand what the writer is saying as-we-read—OR—having a barrage of footnotes to be constantly reminded or (worse) having to look away, loose our place, and look elsewhere to get a “reminder” of context? The more we look away from where we are reading, the more labor is involved, and (with code) the more likely we are to misunderstand, which leads to bugs.
Arguments about code looking like “natural language” might not be so compelling. Code is not a spy thriller, nor ought it be compared to it. It is not flowing English prose. It is code. It will always read like code, look like code, behave like code, operate as code, and have a singular purpose of communicating within the context of a larger system of code to accomplish the job needed by its owner through its creator. A spy novel does not have inheritance, polymorphism, and nor will we ever compile it to run it as machine instructions to tell a machine what to do. Such a comparison is thin at best.
Moreover—a spy novel is not terse, nor is it meant to be. It is meant to tell a story. Nor does it control airplanes, boats, cars, trains, MRIs, spacecraft, or other mission critical machines where human life hangs in the balance if that code goes off the rails. So—better not make too much of a comparison between the code we design and engineer and English prose.
We do not want code to be obfuscated as much as possible. Obfuscation leads to bugs. Eiffel is a carefully and thoughtfully, well tested, and well heeled method with a language and IDE to match. Understanding the method first leads one to quickly see how unnecessary “bad habit” conventions and styles are.
here is a danger in the mock code used as an example. For example: The nearness of `a_balances' to `balances' means that we can replace references to `a_balances' with `balances' in the routine body and the compiler will not complain. The instant we do so, I have created a bug that may be difficult to identify. This might be especially true if there was a reason for the code to make references to both `a_balances' and `balances'. However—even changing the argument name would leave such a situation of potential error unchanged.
CONCLUSION: We have used the prefixing of arguments, locals, attachment locals, and iteration cursor locals for a long time. They have spared us some grief and bugs. We have learned to rest on the good points of having and using them. These differing conventions do not mean we are prevented from using other libraries which use a completely different style! The only place where we ought to agree about convention and style is when we're on the same team, coding within the same system or library. Otherwise, we're all free to agree-to-disagree and do as we please, living happily in our own worlds. Have fun. Enjoy life. Be successful in all you do. My style won't stop you and yours will not stop me. This is a big pond with room enough for all!
(Adapted from Larry Rix, eiffel-users@google, 7 September 2018)