Fixed a spelling mistake and added a small bit about jokes.

git-svn-id: https://svn.apache.org/repos/asf/jakarta/poi/trunk@352398 13f79535-47bb-0310-9956-ffa450edef68
This commit is contained in:
Glen Stampoultzis 2002-04-12 11:13:26 +00:00
parent c5278e4d7e
commit a96c48fd09
1 changed files with 21 additions and 21 deletions

View File

@ -6,7 +6,7 @@
<title>POI Resoluton</title>
<subtitle>Resolution 001 - Minimal Coding Standards</subtitle>
<authors>
<person name="Andrew C. Oliver" email="acoliver@apache.org"/>
<person name="Andrew C. Oliver" email="acoliver@apache.org"/>
</authors>
</header>
@ -20,36 +20,36 @@
styles by working with different code. That being said
there are some universal "good quality" guidelines that
must be adopted on a project of any proportions.
</p>
</p>
<p>
Marc Johnson Authored the following resolution:
</p>
<p>
On Tue, 2002-01-08 at 22:23, Marc Johnson wrote:
Standards are wonderful; everyone should have a set.
Here's what I propose for coding standards for POI WRT comments (should I
Here's what I propose for coding standards for POI WRT comments (should I
feel the need, I'll post more of these little gems):
</p>
<ol>
<li>
All classes and interfaces MUST have, right at the beginning, the POI
All classes and interfaces MUST have, right at the beginning, the POI
License (see poi/doc/LICENSE).
</li>
<li>
All classes and interfaces MUST include class javadoc. Conventionally,
this goes after the package and imports, and before the start of the class
All classes and interfaces MUST include class javadoc. Conventionally,
this goes after the package and imports, and before the start of the class
or interface. The class javadoc MUST have at least one @author tag
</li>
<li>
All methods that are accessible outside the class MUST have javadoc
comments. In other words, if it isn't private, it MUST have javadoc
comments. Simple getters can consist of a simple @return tag; simple setters
can consist of a simple @param tag. Anything else requires some verbiage
plus all the standard javadoc tags as appropriate. You MUST include @throws
or @exception for any non-runtime exceptions, and you SHOULD document any
runtime exceptions you expect to throw. @throws/@exception tags SHOULD
include an explanation of why that exception would be thrown. If your method
might return null, you MUST say so. An accompanying explanation of the
All methods that are accessible outside the class MUST have javadoc
comments. In other words, if it isn't private, it MUST have javadoc
comments. Simple getters can consist of a simple @return tag; simple setters
can consist of a simple @param tag. Anything else requires some verbiage
plus all the standard javadoc tags as appropriate. You MUST include @throws
or @exception for any non-runtime exceptions, and you SHOULD document any
runtime exceptions you expect to throw. @throws/@exception tags SHOULD
include an explanation of why that exception would be thrown. If your method
might return null, you MUST say so. An accompanying explanation of the
circumstances for doing so would be nice.
</li>
</ol>
@ -58,24 +58,24 @@
<section title="License">
<p>
As opposed to the formerly used POI License which was
based on the Apache Public License, now that POI is part of
based on the Apache Public License, now that POI is part of
Jakarta, use the APL 1.1 for the header. Currently, the
Apache Software Foundation requires us to use the full
long version.
</p>
</section>
<section title="2 cents">
</section>
<section title="2 cents">
<p>
Tip: No laughing allow in conversations regarding coding
Tip: No laughing or joking allowed in conversations regarding coding
standards.
Any mail on coding standards will be treated very seriously,
and sent here with a RTFM.
</p>
</section>
</section>
</section>
<section title="Dissent">
<p>
The motion was passed unanimously with no negative or
The motion was passed unanimously with no negative or
positive votes.
</p>
</section>