| 1 |
|
// $Id: README.txt,v 1.6.2.4 2007/10/23 16:29:49 morbus Exp $ |
| 2 |
|
|
| 3 |
|
CONTENTS OF THIS FILE |
| 4 |
|
--------------------- |
| 5 |
|
|
| 6 |
|
* Introduction |
| 7 |
|
* Implemented Reviews |
| 8 |
|
|
| 9 |
|
|
| 10 |
|
INTRODUCTION |
| 11 |
|
------------ |
| 12 |
|
|
| 13 |
|
Current Maintainer: Morbus Iff <morbus@disobey.com> |
| 14 |
|
|
| 15 |
|
Coder Tough Love REQUIRES Coder 6.x-2.x-dev <http://drupal.org/node/314393> |
| 16 |
|
|
| 17 |
|
Coder Tough Love is a companion to the existing Coder module by Doug Green. |
| 18 |
|
Unlike Coder, which strives to follow the documented style guidelines of Drupal |
| 19 |
|
core, Coder Tough Love takes the tougher tactic of applying finely aged and |
| 20 |
|
obsessively anal wisdom from years of Drupal development and persnickety |
| 21 |
|
quality control. |
| 22 |
|
|
| 23 |
|
Part of the reason for this module's creation was to obsess over my own code: |
| 24 |
|
I claim no higher standard than myself, but even I am infinitely fallible. |
| 25 |
|
Likewise, as chx and I wrote DrupalToughLove.com reviews, we found ourselves |
| 26 |
|
repeating suggestions from module to module, and a few of our critiques could |
| 27 |
|
have been automated, leaving us to focus on more important design issues. |
| 28 |
|
|
| 29 |
|
You should expect some false positives with Coder Tough Love, but I'd still |
| 30 |
|
want you to report them as bugs so I can continue to tighten the analysis. |
| 31 |
|
|
| 32 |
|
|
| 33 |
|
IMPLEMENTED REVIEWS |
| 34 |
|
------------------- |
| 35 |
|
|
| 36 |
|
Have some suggestions? Let Morbus, or the issue queue, know! |
| 37 |
|
|
| 38 |
|
A number of reviews focus on Doxygen quality: |
| 39 |
|
|
| 40 |
|
* "Proper documentation is needed for this mysterious blackhole." |
| 41 |
|
Triggers against "@param unknown", "@return unknown_type", etc. |
| 42 |
|
|
| 43 |
|
* "If you define a @param or @return, you should document it as well." |
| 44 |
|
Triggers against "@param $var" with no explanation on the next line. |
| 45 |
|
|
| 46 |
|
* "Doxygen uses @todo and @bug to markup things to be done." |
| 47 |
|
Triggers against "TODO" or "BUG" usage. @todo and @bug are defined |
| 48 |
|
in the Doxygen standards (not the Drupal Doxygen standards). |
| 49 |
|
|
| 50 |
|
* "Separate comments from comment syntax by a space." |
| 51 |
|
Triggers on syntax like "//this" (should be "// this"). |
| 52 |
|
|
| 53 |
|
* "Remove the empty commented line in your function documentation." |
| 54 |
|
We've seen some instances of this style of function Doxygen: |
| 55 |
|
|
| 56 |
|
/** |
| 57 |
|
* Implementation of hook_menu(). |
| 58 |
|
* |
| 59 |
|
*/ |
| 60 |
|
|
| 61 |
|
* "Function documentation should be less than 80 characters per line." |
| 62 |
|
|
| 63 |
|
* "Function summaries should be one line only." |
| 64 |
|
|
| 65 |
|
* "@param and @return syntax does not indicate the data type." |
| 66 |
|
Triggers against "@param int $uid" and similar. While the conceit is |
| 67 |
|
nice (and, apparently, some IDEs do this by default), Drupal core tends |
| 68 |
|
to explain the data type, if at all, in the parameter's documentation. |
| 69 |
|
|
| 70 |
|
* "@param and @return descriptions begin indented on the next line." |
| 71 |
|
Triggers against stuff like "@param $uid the user ID to operate on." |
| 72 |
|
|
| 73 |
|
A number of grammar, spelling, and capitalization rules exist: |
| 74 |
|
|
| 75 |
|
* "Core uses "e-mail" in end-user text and "mail" elsewhere (database, |
| 76 |
|
function names, etc.)" The only exception is valid_email_address(). |
| 77 |
|
|
| 78 |
|
* "Core uses "web server" in end-user text." |
| 79 |
|
|
| 80 |
|
* ""Module" should rarely be capitalized as part of a module\'s proper name." |
| 81 |
|
A lot of people seem to think that the proper name for a module includes |
| 82 |
|
the word "Module", like "the Views Module" or "Coder Module is...". |
| 83 |
|
|
| 84 |
|
* "Use sentence case, not title case, for end-user strings." |
| 85 |
|
Drupal core's strings are written like this, Not All Capitalized Like |
| 86 |
|
This. This complicated rule attempts to find title cased strings. |
| 87 |
|
|
| 88 |
|
* "An unknown or misspelled word has been detected on this line." |
| 89 |
|
If you have the PHP pspell extension installed, Coder Tough Love will |
| 90 |
|
perform spelling checks on all your strings. This is a rule that tends |
| 91 |
|
to give false positives quite easily, since "strings" include a lot |
| 92 |
|
more than just end-user text (SQL, function parameters, etc.). You can |
| 93 |
|
whitelist words at admin/settings/coder_tough_love. |
| 94 |
|
|
| 95 |
|
A number of freshly scented potpourri rules are also shipped: |
| 96 |
|
|
| 97 |
|
* "Use "elseif" not "else if"." |
| 98 |
|
|
| 99 |
|
* "Use the matching Drupal theme functions, not raw HTML." |
| 100 |
|
Triggers against use of A, IMG, or TABLE elements in strings. |
| 101 |
|
|
| 102 |
|
* "Use Drupal's format_date(), not PHP's default date()." |
| 103 |
|
|
| 104 |
|
* "Use PHP's master function, not an alias." |
| 105 |
|
Triggers against use of "sizeof()" instead of "count()", etc. |
| 106 |
|
|
| 107 |
|
* "Administrative menu items should have a description." |
| 108 |
|
When you define an administrative menu, it is also shown, along with a |
| 109 |
|
description, on the primary administrative pages. A lot of developers |
| 110 |
|
have been forgetting to define a description. |
Parent Directory
| 
Revision Log
| 
Revision Graph
| 
Patch