Coding Style Guide
Revision as of 12:31, 14 March 2016 by Hzwakenberg (talk | contribs)
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.