Coding Style Guide

From Liberty Eiffel Wiki
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 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.