    <rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:sy="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:content="http://purl.org/rss/1.0/modules/content/">
     <channel>
        <title>ACCU  :: Commenting Your Work</title>
        <link>https://members.accu.org/index.php/articles/924</link>
        <description>Professionalism in Programming</description>
        <dc:language>en-us</dc:language> 
        <dc:creator>Administrator</dc:creator> 
        <admin:generatorAgent rdf:resource="http://www.xaraya.org" /> 
        <admin:errorReportsTo rdf:resource="mailto:webeditor@accu.org" />
       <sy:updatePeriod>hourly</sy:updatePeriod>
       <sy:updateFrequency>1</sy:updateFrequency>
       <docs>http://backend.userland.com/rss</docs>




<div class="xar-mod-head"><span class="xar-mod-title">CVu Journal Vol 11, #6 - Oct 1999</span></div>

<table border="0" cellpadding="1" cellspacing="0">
    <tbody>
    <tr>
        <td valign="top">
            Browse in :
       </td>
       <td valign="top">

                                            <a href="https://members.accu.org/index.php/articles/">All</a>

                     &gt;                         <a href="https://members.accu.org/index.php/articles/c76/">Journals</a>

                     &gt;                         <a href="https://members.accu.org/index.php/articles/c77/">CVu</a>

                     &gt;                         <a href="https://members.accu.org/index.php/articles/c129/">116</a>
<br />
</td>
   </tr>
   </tbody>
</table>




<div class="xar-error">
   <p>
 <strong>Note:</strong> when you create a new publication type,
the articles module will automatically use the templates
<em>user-display-[publicationtype].xt</em>
and <em>user-summary-[publicationtype].xt</em>.
If those templates do not exist when you try to preview or display a new article,
you'll get this warning :-)  Please place your own templates in themes/<em>yourtheme</em>/modules/articles . The templates will get the extension .xt there. </p>
</div>
<div class="xar-norm xar-standard-box-padding">
   <h1><strong>Title:</strong>&nbsp;Commenting Your Work</h1>
<p><strong>Author:</strong>&nbsp;</p>
<p>
<strong>Date:</strong> 06 October 1999 13:15:33 +01:00 or Wed, 06 October 1999 13:15:33 +01:00</p>
<p><strong>Summary:</strong>&nbsp;</p>
<p><strong>Body:</strong>&nbsp;<div class="sect1" lang="en">
<div class="titlepage">
<h2><a name="d0e20" id="d0e20"></a></h2>
</div>
<p><span class="emphasis"><em>Just to add more confusion to the
comments debate, here is what GNU have to say about it (this was
extracted from the info file on GNU coding
standards)</em></span></p>
<p>Every program should start with a comment saying briefly what it
is for. Example: `fmt - filter for simple filling of text'. Please
put a comment on each function saying what the function does, what
sorts of arguments it gets, and what the possible values of
arguments mean and are used for. It is not necessary to duplicate
in words the meaning of the C argument declarations, if a C type is
being used in its customary fashion. If there is anything
non-standard about its use (such as an argument of type <tt class=
"type">char *</tt> which is really the address of the second
character of a string, not the first), or any possible values that
would not work the way one would expect (such as, that strings
containing newlines are not guaranteed to work), be sure to say
so.</p>
<p>Also explain the significance of the return value, if there is
one.</p>
<p>Please put two spaces after the end of a sentence in your
comments, so that the Emacs sentence commands will work. Also,
please write complete sentences and capitalise the first word. If a
lower-case identifier comes at the beginning of a sentence, don't
capitalise it! Changing the spelling makes it a different
identifier. If you don't like starting a sentence with a lower case
letter, write the sentence differently (e.g., &quot;The identifier
lower-case is ...&quot;).</p>
<p>The comment on a function is much clearer if you use the
argument names to speak about the argument values. The variable
name itself should be lower case, but write it in upper case when
you are speaking about the value rather than the variable itself.
Thus, &quot;the <tt class="varname">inode</tt> number NODE_NUM&quot; rather
than &quot;an <tt class="varname">inode</tt>&quot;.</p>
<p>There is usually no purpose in restating the name of the
function in the comment before it, because the reader can see that
for himself. There might be an exception when the comment is so
long that the function itself would be off the bottom of the
screen. There should be a comment on each <tt class=
"literal">static</tt> variable as well, like this:</p>
<pre class="programlisting">
  /* Nonzero means truncate lines in the display;
     zero means continue them.  */
  int truncate_lines;
</pre>
<p>Every <tt class="literal">#endif</tt> should have a comment,
except in the case of short conditionals (just a few lines) that
are not nested. The comment should state the condition of the
conditional that is ending, including its sense. <tt class=
"literal">#else</tt> should have a comment describing the condition
and sense of the code that follows. For example:</p>
<pre class="programlisting">
  #ifdef foo
    ...
  #else /* not foo */
    ...
  #endif /* not foo */
</pre>
<p>but, by contrast, write the comments this way for a <tt class=
"literal">#ifndef</tt>:</p>
<pre class="programlisting">
#ifndef foo
   ...
#else /* foo */
   ...
#endif /* foo */
</pre></div>
</p>
<p><strong>Notes:</strong>&nbsp;</p>
<p><em>More fields may be available via dynamicdata ..</em></p>
</div>
</channel>
</rss>
