StarMirror/styleguide
1
0
Fork 0
mirror of https://github.com/google/styleguide.git synced 2024-03-22 13:11:43 +08:00
Code Issues Projects Releases Wiki Activity

Update C++ style guide to 3.188:

Browse Source 
- Revise "Smart Pointers" section.
 - Clarify that it's OK to have spaces after '#' in a preprocessor directive,
   even though '#' itself must not be indented.
 - Revise "TODO Comments" section.
 - Fix wording.
 - Explicitly recommend foo.h be the first file #included by foo_test.cc.

Update Objective-C style guide to 2.24:
 - Clarify the spacing of @property declarations.
 - Add "Overridden NSObject Method Placement" section.
 - Explicitly permit blank lines around @interface, @implementation, and @end.

Update JavaScript style guide to 2.20:
 - Provide additional guidance with respect to the compiler.
 - Add {function(new:Type)} as a type syntax for constructors of Type.
 - Revise "Method and Function Comments" section.
 - Harmonize text and example in the "Passing Anonymous Functions" section.
 - Explicitly state that @param and @return types must be enclosed in braces.
 - Add documentation on the UNKNOWN type.
 - Replace a CODE_SNIPPET with BAD_CODE_SNIPPET in the "Internet Explorer's
   Conditional Comments" section.
 - Remove a redundant "Expand for more information" in the "Naming" section
   and fully spell out "information" in the "Code Formatting" section.
 - Provide a positive example in the "Multiline string literals" section.
 - Provide guidance for indentation within nested functions.

Update Python style guide to 2.20:
 - Clarify shebang rule.
This commit is contained in:
mmentovai 2011-03-29 20:30:47 +00:00
parent 222e6da82a
commit cd4ce0fff0
4 changed files with 243 additions and 97 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

101
cppguide.xml
View File

@ -4,7 +4,7 @@
<p align="right">
Revision 3.180
Revision 3.188
</p>
@ -161,7 +161,7 @@ Tashana Landray
header files.
</p>
<p>
You can significantly minimize the number of header files you
You can significantly reduce the number of header files you
need to include in your own header files by using forward
declarations. For example, if your header file uses the
<code>File</code> class in ways that do not require access to
@ -355,7 +355,7 @@ Tashana Landray
<p>
All of a project's header files should be
listed as descentants of the project's source directory
listed as descendants of the project's source directory
without use of UNIX directory shortcuts <code>.</code> (the current
directory) or <code>..</code> (the parent directory). For
example,
@ -367,8 +367,8 @@ Tashana Landray
#include "base/logging.h"
</CODE_SNIPPET>
<p>
In <code><var>dir/foo</var>.cc</code>, whose main purpose is
to implement or test the stuff in
In <code><var>dir/foo</var>.cc</code> or <code><var>dir/foo_test</var>.cc</code>,
whose main purpose is to implement or test the stuff in
<code><var>dir2/foo2</var>.h</code>, order your includes as
follows:
</p>
@ -1464,34 +1464,46 @@ Tashana Landray
<SUMMARY>
If you actually need pointer semantics, <code>scoped_ptr</code>
is great. You should only use <code>std::tr1::shared_ptr</code>
under very specific conditions, such as when objects need to be
held by STL containers. You should never use <code>auto_ptr</code>.
with a non-const referent when it is truly necessary to share ownership
of an object (e.g. inside an STL container). You should never use
<code>auto_ptr</code>.
</SUMMARY>
<BODY>
<p>
"Smart" pointers are objects that act like pointers but have
added semantics. When a <code>scoped_ptr</code> is
destroyed, for instance, it deletes the object it's pointing
to. <code>shared_ptr</code> is the same way, but implements
reference-counting so only the last pointer to an object
deletes it.
</p>
<p>
Generally speaking, we prefer that we design code with clear
object ownership. The clearest object ownership is obtained by
using an object directly as a field or local variable, without
using pointers at all. On the other extreme, by their very definition,
reference counted pointers are owned by nobody. The problem with
this design is that it is easy to create circular references or other
strange conditions that cause an object to never be deleted.
It is also slow to perform atomic operations every time a value is
copied or assigned.
</p>
<p>
Although they are not recommended, reference counted pointers are
sometimes the simplest and most elegant way to solve a problem.
</p>
<DEFINITION>
"Smart" pointers are objects that act like pointers, but automate
management of the underlying memory.
</DEFINITION>
<PROS>
Smart pointers are extremely useful for preventing memory leaks, and
are essential for writing exception-safe code. They also formalize
and document the ownership of dynamically allocated memory.
</PROS>
<CONS>
We prefer designs in which objects have single, fixed owners. Smart
pointers which enable sharing or transfer of ownership can act as a
tempting alternative to a careful design of ownership semantics,
leading to confusing code and even bugs in which memory is never
deleted. The semantics of smart pointers (especially
<code>auto_ptr</code>) can be nonobvious and confusing. The
exception-safety benefits of smart pointers are not decisive, since
we do not allow exceptions.
</CONS>
<DECISION>
<dl>
<dt><code>scoped_ptr</code></dt>
<dd>Straightforward and risk-free. Use wherever appropriate.</dd>
<dt><code>auto_ptr</code></dt>
<dd>Confusing and bug-prone ownership-transfer semantics. Do not use.
</dd>
<dt><code>shared_ptr</code></dt>
<dd>
Safe with const referents (i.e. <code>shared_ptr&lt;const
T&gt;</code>). Reference-counted pointers with non-const referents
can occasionally be the best design, but try to rewrite with single
owners where possible.
</dd>
</dl>
</DECISION>
</BODY>
</STYLEPOINT>
@ -3456,14 +3468,20 @@ Tashana Landray
<BODY>
<p>
<code>TODO</code>s should include the string <code>TODO</code> in
all caps, followed by your
all caps, followed by the
name, e-mail address, or other
identifier
in parentheses. A colon is optional. The main purpose is to have
a consistent <code>TODO</code> format searchable by the person
adding the comment (who can provide more details upon request). A
<code>TODO</code> is not a commitment to provide the fix yourself.
of the person who can best provide context about the problem
referenced by the <code>TODO</code>. A colon is optional. The main
purpose is to have a consistent <code>TODO</code> format that can be
searched to find the person who can provide more details upon request.
A <code>TODO</code> is not a commitment that the person referenced
will fix the problem. Thus when you create a <code>TODO</code>, it is
almost always your
name
that is given.
</p>
<CODE_SNIPPET>
@ -4105,12 +4123,12 @@ Tashana Landray
<STYLEPOINT title="Preprocessor Directives">
<SUMMARY>
Preprocessor directives should not be indented but should
instead start at the beginning of the line.
The hash mark that starts a preprocessor directive should
always be at the beginning of the line.
</SUMMARY>
<BODY>
<p>
Even when pre-processor directives are within the body of
Even when preprocessor directives are within the body of
indented code, the directives should start at the beginning of
the line.
</p>
@ -4119,6 +4137,9 @@ Tashana Landray
if (lopsided_score) {
#if DISASTER_PENDING // Correct -- Starts at beginning of line
DropEverything();
# if NOTIFY // OK but not required -- Spaces after #
NotifyClient();
# endif
#endif
BackToNormal();
}
@ -4529,7 +4550,7 @@ Tashana Landray
<HR/>
<p align="right">
Revision 3.180
Revision 3.188
</p>

144
javascriptguide.xml
View File

@ -3,7 +3,7 @@
<GUIDE title="Google JavaScript Style Guide">
<p class="revision">
Revision 2.11
Revision 2.20
</p>
<address>
@ -504,6 +504,15 @@
at compile time; whitespace after the slash will result in tricky
errors; and while most script engines support this, it is not part
of ECMAScript. </p>
<p>Use string concatenation instead:</p>
<CODE_SNIPPET>
var myString = 'A rather long string of English text, an error message ' +
'actually that just keeps going and going -- an error ' +
'message to make the Energizer bunny blush (right through ' +
'those Schwarzenegger shades)! Where was I? Oh yes, ' +
'you\'ve got an error and all the extraneous whitespace is ' +
'just gravy. Have a nice day.';
</CODE_SNIPPET>
</BODY>
</STYLEPOINT>
@ -579,11 +588,11 @@
<SUMMARY>No</SUMMARY>
<BODY>
<p>Don't do this:</p>
<CODE_SNIPPET>
<BAD_CODE_SNIPPET>
var f = function () {
/*@cc_on if (@_jscript) { return 2* @*/ 3; /*@ } @*/
};
</CODE_SNIPPET>
</BAD_CODE_SNIPPET>
<p>Conditional Comments hinder automated tools as they can vary the
JavaScript syntax tree at runtime.</p>
</BODY>
@ -597,7 +606,6 @@
<code>variableNamesLikeThis</code>, <code>ClassNamesLikeThis</code>,
<code>EnumNamesLikeThis</code>, <code>methodNamesLikeThis</code>,
and <code>SYMBOLIC_CONSTANTS_LIKE_THIS</code>.</p>
<p>Expand for more information.</p>
</SUMMARY>
<BODY>
<SUBSECTION title="Properties and methods">
@ -830,7 +838,7 @@
</STYLEPOINT>
<STYLEPOINT title="Code formatting">
<SUMMARY>Expand for more info.</SUMMARY>
<SUMMARY>Expand for more information.</SUMMARY>
<BODY>
<p>We follow the <a href="cppguide.xml#Formatting">C++ formatting
rules</a> in spirit, with the following additional clarifications.</p>
@ -943,19 +951,29 @@
// ...
}
</CODE_SNIPPET>
<p>When the function call is itself indented, you're free to start the
4-space indent relative to the beginning of the original statement
or relative to the beginning of the current function call.
The following are all acceptable indentation styles.</p>
<CODE_SNIPPET>
if (veryLongFunctionNameA(
veryLongArgumentName) ||
veryLongFunctionNameB(
veryLongArgumentName)) {
veryLongFunctionNameC(veryLongFunctionNameD(
veryLongFunctioNameE(
veryLongFunctionNameF)));
}
</CODE_SNIPPET>
</SUBSECTION>
<SUBSECTION title="Passing Anonymous Functions">
<p>When declaring an anonymous function in the list of arguments for
a function call, the body of the function is indented two spaces
from the left edge of the function call or the statement, not two
spaces from the left edge of the function keyword. This is to make
the body of the anonymous function easier to read (i.e. not be all
squished up into the right half of the screen).</p>
from the left edge of the statement, or two spaces from the left
edge of the function keyword. This is to make the body of the
anonymous function easier to read (i.e. not be all squished up into
the right half of the screen).</p>
<CODE_SNIPPET>
var names = items.map(function(item) {
return item.name;
});
prefix.something.reallyLongFunctionName('whatever', function(a1, a2) {
if (a1.equals(a2)) {
someOtherLongFunctionName(a1);
@ -963,6 +981,12 @@
andNowForSomethingCompletelyDifferent(a2.parrot);
}
});
var names = prefix.something.myExcellentMapFunction(
verboselyNamedCollectionOfItems,
function(item) {
return item.name;
});
</CODE_SNIPPET>
</SUBSECTION>
<SUBSECTION title="More Indentation">
@ -1063,7 +1087,12 @@
<p>We recommend the use of the JSDoc annotations <code>@private</code> and
<code>@protected</code> to indicate visibility levels for classes,
functions, and properties.</p>
<p>The --jscomp_warning=visibility compiler flag turns on compiler
warnings for visibility violations. See
<a href="http://code.google.com/p/closure-compiler/wiki/Warnings">
Closure Compiler
Warnings</a>.
</p>
<p><code>@private</code> global variables and functions are only
accessible to code in the same file.</p>
<p>Constructors marked <code>@private</code> may only be instantiated by
@ -1301,6 +1330,18 @@
<td/>
</tr>
<tr>
<td>Function <code>new</code> Type</td>
<td>
<code>{function(new:goog.ui.Menu, string)}</code><br/>
A constructor that takes one argument (a string), and
creates a new instance of goog.ui.Menu when called
with the 'new' keyword.
</td>
<td>Specifies the constructed type of a constructor.</td>
<td/>
</tr>
<tr>
<td>Variable arguments</td>
<td>
@ -1361,6 +1402,14 @@
<td>Indicates that the variable can take on any type.</td>
<td/>
</tr>
<tr>
<td>The UNKNOWN type</td>
<td><code>{?}</code></td>
<td>Indicates that the variable can take on any type,
and the compiler should not type-check any uses of it.</td>
<td/>
</tr>
</tbody>
</table>
</SUBSECTION>
@ -1900,10 +1949,10 @@
</SUBSECTION>
<SUBSECTION title="Method and Function Comments">
<p>A description must be provided along with parameters. Use full
sentences. Method descriptions should start with a sentence written
in the third person declarative voice.</p>
<p>A description must be provided along with parameters.
When appropriate or necessary, use full sentences. Method
descriptions should start with a sentence written in the third
person declarative voice.</p>
<CODE_SNIPPET>
/**
* Converts text to some completely different text.
@ -2064,7 +2113,29 @@
</CODE_SNIPPET>
</SUBSECTION>
<SUBSECTION title="Template types">
<a name="Template_types"/>
<p>The compiler has limited support for template types. It can only
infer the type of <tt>this</tt> inside an anonymous function
literal from the type of the <tt>this</tt> argument and whether the
<tt>this</tt> argument is missing.</p>
<CODE_SNIPPET>
/**
* @param {function(this:T, ...)} fn
* @param {T} thisObj
* @param {...*} var_args
* @template T
*/
goog.bind = function(fn, thisObj, var_args) {
...
};
// Possibly generates a missing property warning.
goog.bind(function() { this.someProperty; }, new SomeClass());
// Generates an undefined this warning.
goog.bind(function() { this.someProperty; });
</CODE_SNIPPET>
</SUBSECTION>
<SUBSECTION title="JSDoc Tag Reference">
<table border="1" style="border-collapse:collapse" cellpadding="4">
@ -2096,7 +2167,10 @@
</td>
<td>
Used with method, function and constructor calls to document
the arguments of a function.
the arguments of a function.<p/>
Type names must be enclosed in curly braces. If the type
is omitted, the compiler will not type-check the parameter.
</td>
<td>Fully supported.</td>
</tr>
@ -2121,7 +2195,10 @@
type. When writing descriptions for boolean parameters,
prefer "Whether the component is visible" to "True if the
component is visible, false otherwise". If there is no return
value, do not use an <code>@return</code> tag.
value, do not use an <code>@return</code> tag.<p/>
Type names must be enclosed in curly braces. If the type
is omitted, the compiler will not type-check the return value.
</td>
<td>Fully supported.</td>
</tr>
@ -2757,7 +2834,28 @@
<td>Yes</td>
</tr>
<tr>
<td><a name="tag-template">@template</a></td>
<td>
<tt>@template</tt>
<p><i>For example:</i></p>
<CODE_SNIPPET>
/**
* @param {function(this:T, ...)} fn
* @param {T} thisObj
* @param {...*} var_args
* @template T
*/
goog.bind = function(fn, thisObj, var_args) {
...
};
</CODE_SNIPPET>
</td>
<td>
This annotation can be used to declare a template typename.
</td>
<td>Yes with <a href="#Template_types">limitations.</a></td>
</tr>
<tr>
<td><a name="tag-externs">@externs</a></td>
@ -3155,7 +3253,7 @@
</PARTING_WORDS>
<p align="right">
Revision 2.11
Revision 2.20
</p>

37
objcguide.xml
View File

@ -4,7 +4,7 @@
<p align="right">
Revision 2.21
Revision 2.24
</p>
@ -169,7 +169,7 @@ Revision 2.21
</CODE_SNIPPET>
<p>
An example source file, demonstating the correct commenting and spacing
An example source file, demonstrating the correct commenting and spacing
for the <code>@implementation</code> of an interface. It also includes the
reference implementations for important methods like getters and setters,
<code>init</code>, and <code>dealloc</code>.
@ -229,6 +229,18 @@ Revision 2.21
@end
</CODE_SNIPPET>
<p>
Blank lines before and after <code>@interface</code>,
<code>@implementation</code>, and <code>@end</code> are optional. If your
<code>@interface</code> declares instance variables, as most do, any blank
line should come after the closing brace (<code>}</code>).
<p>
</p>
Unless an interface or implementation is very short, such as when declaring
a handful of private methods or a bridge class, adding blank lines usually
helps readability.
</p>
</CATEGORY>
<CATEGORY title="Spacing And Formatting">
@ -918,6 +930,21 @@ Revision 2.21
</BODY>
</STYLEPOINT>
<STYLEPOINT title="Overridden NSObject Method Placement">
<SUMMARY>
It is strongly recommended and typical practice to place overridden
methods of <code>NSObject</code> at the top of an
<code>@implementation</code>.
</SUMMARY>
<BODY>
This commonly applies (but is not limited) to the <code>init...</code>,
<code>copyWithZone:</code>, and <code>dealloc</code> methods.
<code>init...</code> methods should be grouped together, followed by
the <code>copyWithZone:</code> method, and finally the
<code>dealloc</code> method.
</BODY>
</STYLEPOINT>
<STYLEPOINT title="Initialization">
<SUMMARY>
Don't initialize variables to <code>0</code> or <code>nil</code> in the
@ -1368,7 +1395,9 @@ Revision 2.21
<p>
A property's associated instance variable's name must conform to the
trailing _ requirement. The property's name should be the same as its
associated instance variable without the trailing _.
associated instance variable without the trailing _. The optional
space between the <code>@property</code> and the opening parenthesis
should be omitted, as seen in the examples.
</p>
<p>
Use the @synthesize directive to rename the property correctly.
@ -1572,7 +1601,7 @@ Revision 2.21
<HR/>
<p align="right">
Revision 2.21
Revision 2.24
</p>

58
pyguide.html
View File

@ -100,7 +100,7 @@
<H1>Google Python Style Guide</H1>
<p align="right">
Revision 2.19
Revision 2.20
</p>
<address>
@ -134,7 +134,7 @@
<TR valign="top" class="">
<TD><DIV class="toc_category"><A href="#Python_Style_Rules">Python Style Rules</A></DIV></TD>
<TD><DIV class="toc_stylepoint">
<SPAN style="padding-right: 1em; white-space:nowrap;" class=""><A href="#Semicolons">Semicolons</A></SPAN> <SPAN style="padding-right: 1em; white-space:nowrap;" class=""><A href="#Line_length">Line length</A></SPAN> <SPAN style="padding-right: 1em; white-space:nowrap;" class=""><A href="#Parentheses">Parentheses</A></SPAN> <SPAN style="padding-right: 1em; white-space:nowrap;" class=""><A href="#Indentation">Indentation</A></SPAN> <SPAN style="padding-right: 1em; white-space:nowrap;" class=""><A href="#Blank_Lines">Blank Lines</A></SPAN> <SPAN style="padding-right: 1em; white-space:nowrap;" class=""><A href="#Whitespace">Whitespace</A></SPAN> <SPAN style="padding-right: 1em; white-space:nowrap;" class=""><A href="#Python_Interpreter">Python Interpreter</A></SPAN> <SPAN style="padding-right: 1em; white-space:nowrap;" class=""><A href="#Comments">Comments</A></SPAN> <SPAN style="padding-right: 1em; white-space:nowrap;" class=""><A href="#Classes">Classes</A></SPAN> <SPAN style="padding-right: 1em; white-space:nowrap;" class=""><A href="#Strings">Strings</A></SPAN> <SPAN style="padding-right: 1em; white-space:nowrap;" class=""><A href="#TODO_Comments">TODO Comments</A></SPAN> <SPAN style="padding-right: 1em; white-space:nowrap;" class=""><A href="#Imports_formatting">Imports formatting</A></SPAN> <SPAN style="padding-right: 1em; white-space:nowrap;" class=""><A href="#Statements">Statements</A></SPAN> <SPAN style="padding-right: 1em; white-space:nowrap;" class=""><A href="#Access_Control">Access Control</A></SPAN> <SPAN style="padding-right: 1em; white-space:nowrap;" class=""><A href="#Naming">Naming</A></SPAN> <SPAN style="padding-right: 1em; white-space:nowrap;" class=""><A href="#Main">Main</A></SPAN> </DIV></TD>
<SPAN style="padding-right: 1em; white-space:nowrap;" class=""><A href="#Semicolons">Semicolons</A></SPAN> <SPAN style="padding-right: 1em; white-space:nowrap;" class=""><A href="#Line_length">Line length</A></SPAN> <SPAN style="padding-right: 1em; white-space:nowrap;" class=""><A href="#Parentheses">Parentheses</A></SPAN> <SPAN style="padding-right: 1em; white-space:nowrap;" class=""><A href="#Indentation">Indentation</A></SPAN> <SPAN style="padding-right: 1em; white-space:nowrap;" class=""><A href="#Blank_Lines">Blank Lines</A></SPAN> <SPAN style="padding-right: 1em; white-space:nowrap;" class=""><A href="#Whitespace">Whitespace</A></SPAN> <SPAN style="padding-right: 1em; white-space:nowrap;" class=""><A href="#Shebang_Line">Shebang Line</A></SPAN> <SPAN style="padding-right: 1em; white-space:nowrap;" class=""><A href="#Comments">Comments</A></SPAN> <SPAN style="padding-right: 1em; white-space:nowrap;" class=""><A href="#Classes">Classes</A></SPAN> <SPAN style="padding-right: 1em; white-space:nowrap;" class=""><A href="#Strings">Strings</A></SPAN> <SPAN style="padding-right: 1em; white-space:nowrap;" class=""><A href="#TODO_Comments">TODO Comments</A></SPAN> <SPAN style="padding-right: 1em; white-space:nowrap;" class=""><A href="#Imports_formatting">Imports formatting</A></SPAN> <SPAN style="padding-right: 1em; white-space:nowrap;" class=""><A href="#Statements">Statements</A></SPAN> <SPAN style="padding-right: 1em; white-space:nowrap;" class=""><A href="#Access_Control">Access Control</A></SPAN> <SPAN style="padding-right: 1em; white-space:nowrap;" class=""><A href="#Naming">Naming</A></SPAN> <SPAN style="padding-right: 1em; white-space:nowrap;" class=""><A href="#Main">Main</A></SPAN> </DIV></TD>
</TR>
</TABLE>
</DIV>
@ -1370,36 +1370,34 @@ from sound.effects import echo
</DIV></DIV>
</DIV>
<DIV class="">
<H3><A name="Python_Interpreter" id="Python_Interpreter">Python Interpreter</A></H3>
<SPAN class="link_button" id="link-Python_Interpreter__button" name="link-Python_Interpreter__button"><A href="?showone=Python_Interpreter#Python_Interpreter">
link
</A></SPAN><SPAN class="showhide_button" onclick="javascript:ShowHideByName('Python_Interpreter__body','Python_Interpreter__button')" name="Python_Interpreter__button" id="Python_Interpreter__button">▶</SPAN>
<DIV style="display:inline;" class="">
Modules should begin with
<code>#!/usr/bin/env python&lt;version&gt;</code>
</DIV>
<DIV class=""><DIV class="stylepoint_body" name="Python_Interpreter__body" id="Python_Interpreter__body" style="display: none">
<p>
Modules should begin with a "shebang" line specifying the Python
interpreter used to execute the program:
</p>
<DIV class=""><PRE>
<span class="external"></span>#!/usr/bin/env python2.4</PRE></DIV>
<p>
Always use the most specific version you can use, e.g.,
<code>/usr/bin/python2.4</code>, not
<code>/usr/bin/python2</code>. This makes it easier to find
dependencies when upgrading to a different Python version
and also avoids confusion and breakage during use. E.g., Does
<code>/usr/bin/python2</code> mean Python 2.0.1 or Python 2.3.0?
</p>
<a name="Python_Interpreter"></a>
<DIV class="">
<H3><A name="Shebang_Line" id="Shebang_Line">Shebang Line</A></H3>
<SPAN class="link_button" id="link-Shebang_Line__button" name="link-Shebang_Line__button"><A href="?showone=Shebang_Line#Shebang_Line">
link
</A></SPAN><SPAN class="showhide_button" onclick="javascript:ShowHideByName('Shebang_Line__body','Shebang_Line__button')" name="Shebang_Line__button" id="Shebang_Line__button">▶</SPAN>
<DIV style="display:inline;" class="">
All <code>.py</code> files (except <code>__init__.py</code> package
files) should begin with a
<code>#!/usr/bin/python&lt;version&gt;</code>
shebang line.
</DIV>
<DIV class=""><DIV class="stylepoint_body" name="Shebang_Line__body" id="Shebang_Line__body" style="display: none">
<p>
Always use the most specific version that you can to ensure
compatibility. For examples, if your program uses a language feature
that that first appeared in Python 2.4, use
<code>/usr/bin/python2.4</code> (or something newer) instead of
<code>/usr/bin/python2</code>. Otherwise, your program might not
behave the way you expect it to, because the interpreter uses an
older version of the language.
</p>
</DIV></DIV>
</DIV>
<DIV class="">
<H3><A name="Comments" id="Comments">Comments</A></H3>
<SPAN class="link_button" id="link-Comments__button" name="link-Comments__button"><A href="?showone=Comments#Comments">
@ -2029,7 +2027,7 @@ Don'<span class="external"></span>t do this.
<p align="right">
Revision 2.19
Revision 2.20
</p>