Difference between revisions of "Coding Style Guide"

From Liberty Eiffel Wiki
Jump to navigation Jump to search
m
 
Line 3: Line 3:
 
* try to choose feature names that would make code read (as much as) the English language.
 
* try to choose feature names that would make code read (as much as) the English language.
 
* boolean queries should be named <code>is_....</code>, e.g. <code>is_empty</code>
 
* boolean queries should be named <code>is_....</code>, e.g. <code>is_empty</code>
* 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 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".
+
* 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.
 
* 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
 
* omit feature comments in case the feature name fully explains the feature

Latest revision as of 13:31, 14 March 2016

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 and creation 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 explicit Current! 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.