View source for Eiffel Code Comments

[[Category:Coding Style Guidelines]]
[[Category:Coding Standards]]
==Comment Mark Up ==
The Eiffel compiler and EiffelStudio's code browsing tools support a special, light-weight mark up in comments and strings for referencing classes and features. EiffelStudio's code browsing tools utilize this mark up to better facilitate code navigation and browsing. In addition, marked up comments and strings will be examined and altered when performing a class or feature ''rename'' refactoring.

===Syntax===
The syntax for marking up classes and features is very compact, to ensure retained legibility. You'll see no need for XML or other types of verbose mark up found in other languages, which can impede the comment's very nature as a quick reference.

To mark up a class reference, surround the class name in an open ('''{''') and matching closing ('''}''') brace:

<e>
-- See {DEBUG_OUTPUT} for more information.
</e>

To mark up a feature reference, implemented in the same class or parent, surround the feature name in a single back quote (`) and a matching closing single quote ('):

<e>
-- See `debug_output' for more information.
</e>

In the case where a reference to a feature is not accessible to the containing class directly, use a combination of the class reference mark up and a feature name, ''sans'' quotation marks:

<e>
-- See {DEBUG_OUTPUT}.debug_output for more information.
</e>

The rules that apply for comments, as described above, can also be utilized in any manifest or verbatim string:

<e>
note
    description: "Augments searching facilities of {STRING_8}"
</e>

==Precursor Comments==

{{Version|6.2}}

Precursor comments declarations are a new mechanism added to EiffelStudio 6.2 to replicate a parent feature declaration's comments in the redefined/effective feature. The purpose of the mechanism is to reduce comment duplication, ease comment maintenance and facilitate augmentation.

For the purpose of demonstration, take the following deferred interface:
<e>
deferred class
  BASE

feature -- Query

  test (a_arg: INTEGER): BOOLEAN
      -- Comments for a feature.
      --
      -- `a_arg': An integer value.
      -- `Result': Could be True or False.
    deferred
    end

end
</e>

And effective implementation of it:

<e>
class
  TEST

inherit
  BASE

feature -- Query

  test (a_arg: INTEGER): BOOLEAN
            -- <Precursor>
        do
        end

end
</e>

<e>TEST</e> instead of replicating the comment makes use of the precursor comment declaration (<e>-- <Precursor></e>), which supporting code browsing tool will expand to show the precursor feature's contracts. The declaration is optional but is only supported for existing code out there that do not have comments due to lax implementation. Even though optional, it is strongly recommended that you use <e>-- <Precursor></e> comment declaration, as it indicates to any reader the feature is a redefinition or effective implementation of a parent feature declaration.

=== Comment Augmentation ===
The precursor comments declaration also supports augmentation. All a comment author has to do is to write additional comments before and/or after the precursor comment declaration. As a requirement, the precursor comment declaration must appear on a separate line for no other purpose except for clarity. Failure to do so will results in the rendering of the comments as they are declared in the feature, i.e. with <e>-- <Precursor></e> as is.

<e>
test (a_arg: INTEGER): BOOLEAN
    -- Comments before the original comments from {BASE}.
    --
    -- <Precursor>
    --
    -- Some additional comments.
  do
  end
</e>

Using the code browsing facilities of [[EiffelStudio]] the reader will be presented with an expanded comment, for the effective version of feature <e>test</e>, that now read

<e>
-- Comments before the original comments from {BASE}.
--
-- Comments for a feature.
--
-- `a_arg': An integer value.
-- `Result': Could be True or False.
--
-- Some additional comments.
</e>

For clarity it is a good idea to separate the agumented comments from the precursor comment declaration. Using the same example above but removing the one line spacing above and below the precursor comment declaration would results in the following, less readable comment:

<e>
-- Comments before the original comments from {BASE}.
-- Comments for a feature.
--
-- `a_arg': An integer value.
-- `Result': Could be True or False.
-- Some additional comments.
</e>

However, that said, it is pure discretion to use additional spacing or not. Some situation do not call for, other do and some might (when the original comment changes.)

=== Multiple Redefinitions and Selection ===
With Eiffel supporting multiple inheritance, a scenario will arise where two inherited redefine features are joined in a descendant.

By default the precursor comment declaration is replaced by the first located inherited feature comment, which may cause documentation irregularities. Because precursor comments are not signification to compilation they are not checked during compilation, such as is the way with the use of <e>Precursor</e>, resulting a compile time error when not selecting the parent class to call into. This can cause documentation irregularities because there is no guarantee that they feature comments viewed one project will be the same in another.

To facilitate correct documentation the precursor comment declaration can use an optional select clause, just like using <e>Precursor</e> in the Eiffel code.

<e>
f (a_arg: INTEGER): BOOLEAN
        -- <Precursor {BASE}>
     do
     end
</e>

This will have exactly the same effect as using <e>-- <Precursor></e> when <e>f</e> is made effective/redefined from a single parent. However, when making effective/redefining from multiple parents then comments will come from the parent class declaration in <e>BASE</e>.

Again, because precursor comments do not affect compilation they are not checked at compile time. Specifying an incorrect class will yield a warning message in [[EiffelStudio]]'s code browsing tools, to the effect:

<e>
-- Unable to retrieve the comments from redefinition of {CLASS_NAME}.
</e>

=== Library Documentation Generation ===
Precursor comments are supported in all code browsing/documentation facilities, whether is be the integrated [[Contract Viewer]], the [[Feature Relation Tool]] or the Eiffel documentation generation facilities. Using <e>-- <Precursor></e> will ensure the comments are brought up from a parent declaration.