[development] QA: Consensus on comment formatting

Angela Byron drupal-devel at webchick.net
Mon Jan 8 15:43:39 UTC 2007


Excellent! Thanks for the summary, Derek!!

> Here's a new draft of the conventions given everyone's input, my  
> votes above, and a few other suggestions:
>
>
> * Comments should be written in English, with correct spelling[2],  
> punctuation, and grammar.
> * Being concise is best, but never at the expense of clarity.
> * Comments are capitalized and end in periods. They should be  
> complete sentences on their own line unless they are documenting  
> lists, or are describing a line of code that only needs a few extra  
> words to be clear. sentences are separated by a single space.[3]
> * @file documentation begins with a sentence in present tense, and  
> has a blank line before any further comments.
> * Function documentation begins with a single sentence in the form  
> "Do such and such." rather than "Does such and such.", and has a  
> blank line before any further comments.
> * There is a blank line between @param and @return sections in  
> function documentation.
> * Comments should not use all caps, e.g, NOTE. Instead, use @note,  
> @todo, @warning, @bug, etc.
> * Any comment that refers to a variable should include the dollar- 
> sign in front of the $variable_name.
> * Any comment that refers a database table should use {table_name}  
> to make it visually unique, not "table_name", 'table_name', etc.
> * In general, URLs, code snippets, file names, etc, should not be  
> enclosed in quotation marks (") or inverted commas (') unless it  
> significantly enhances readability. Where necessary, inverted  
> commas should be used rather than quotation marks.
> * No comment should be, or cause a line of code to become, wider  
> than 80 characters.
> * In general, comments should not refer to issue node ids (for  
> example, "// This is crazy, and we fixed it in #12345."), since  
> that's what the CVS annotation and commit logs are for. However,  
> links to issues are allowed (recommended?) in a @todo or @bug. In  
> this case, a full URL should be used. For example:
>   // @todo These queries are very expensive, see http://drupal.org/ 
> node/105639.
>

Now, just one (technical) question.

Does this:


>   // @todo These queries are very expensive, see http://drupal.org/ 
> node/105639.
>

...actually work and get parsed by doxygen?? I thought doxygen only  
worked on function headers. This would make @todo less useful, imo,  
since:

     // TODO: this can be an expensive query. Perhaps only execute it  
every x minutes. Requires investigation into cache expiration.
     if ($user->uid) {
       db_query("UPDATE {users} SET access = %d WHERE uid = %d", time 
(), $user->uid);
     }

Tells me that the queries immediately following that line are  
expensive, vs.

/**
  * Reads a session variable.
  *
  * @todo the update query used here can be expensive....
  */
function sess_read($key) {

Anyone know?

Also, as Robert brought up, // TODO, etc. have support in IDEs (Zend,  
etc.). Can someone check if @todo does as well?

-Angie




More information about the development mailing list