svn commit: r950639 - in /websites/staging/pdfbox/trunk/content: ./ codingconventions.html

[bu...@apache.org]

Author: buildbot
Date: Fri May  8 19:28:16 2015
New Revision: 950639

Log:
Staging update by buildbot for pdfbox

Modified:
    websites/staging/pdfbox/trunk/content/   (props changed)
    websites/staging/pdfbox/trunk/content/codingconventions.html

Propchange: websites/staging/pdfbox/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Fri May  8 19:28:16 2015
@@ -1 +1 @@
-1678439
+1678440

Modified: websites/staging/pdfbox/trunk/content/codingconventions.html
==============================================================================
--- websites/staging/pdfbox/trunk/content/codingconventions.html (original)
+++ websites/staging/pdfbox/trunk/content/codingconventions.html Fri May  8 19:28:16 2015
@@ -258,7 +258,7 @@ Methods  </p>
 <p>Give variables and methods meaningful names. Keep these short but don't use abbreviations. Prefer using the same terminology as the PDF spec.</p>
 </li>
 <li>
-<p>Prefer final classes and final protected methods for non-final public classes, this reduces the surface area of the public API</p>
+<p>Prefer final classes and final protected methods for non-final public classes, this reduces the surface area of the public API.</p>
 </li>
 <li>
 <p>Avoid non-final protected variables in public classes. Prefer protected getters over protected variables when protected fields are necessery in public classes.</p>
@@ -267,7 +267,7 @@ Methods  </p>
 <p>Minimize the API. Don't make everything public just because you can.</p>
 </li>
 <li>
-<p>Don't expose implementation details unless there is a clear need: allowing subclassing means that the behaviour of protected methods becomes part of the contract of the public AP</p>
+<p>Don't expose implementation details unless there is a clear need: allowing subclassing means that the behaviour of protected methods becomes part of the contract of the public AP.</p>
 </li>
 <li>
 <p>Avoid unnecesary abstraction. While you're encouraged to avoid brittle designs, it's unlikey that an API designed for "future use" will have the correct API without any code which actually uses it.</p>