Coding Style Guide
Jump to navigation
Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
Some proposals on how to format and comment code; usual common Eiffel practices are recommended of course.
- try to choose feature names that would make code read (as much as) the English language.
- boolean queries should be named
is_....
, e.g.is_empty
- Describe each feature. Do not leave any feature without a description; while it is surely obvious for the feature writer it may not be so manifest to another person. What does a command do? What's the meaning of a query? Avoid phrasing like "This feature opens a window", write instead "Opens a window"; instead of "This function returns the number of acorns in tree-hole" write "Number of acorns in the tree-hole".
- try to name feature argument prefixing them with generic English preposition (a_, an_, some_); this make core-reading more fluent.
- omit feature comments in case the feature name fully explains the feature
- use correct indentation
feature
andcreation
clauses should always have an explicit client list (Liberty will raise a warning otherwise). Of course it may be{ANY}
. An empty list i.e.{}
means that only unqualified calls are possible (i. e. the *implicit*Current
target, not the explicitCurrent
! may use it);{NONE}
is discouraged as the NONE adds no information at all.- use 3 spaces for indentation, no TAB
Feel free to make any proposal and improvements.