svn commit: r1678440 - /pdfbox/cmssite/trunk/content/codingconventions.mdtext

[ja...@apache.org]

Author: jahewson
Date: Fri May  8 19:28:04 2015
New Revision: 1678440

URL: http://svn.apache.org/r1678440
Log:
Formatting fix

Modified:
    pdfbox/cmssite/trunk/content/codingconventions.mdtext

Modified: pdfbox/cmssite/trunk/content/codingconventions.mdtext
URL: http://svn.apache.org/viewvc/pdfbox/cmssite/trunk/content/codingconventions.mdtext?rev=1678440&r1=1678439&r2=1678440&view=diff
==============================================================================
--- pdfbox/cmssite/trunk/content/codingconventions.mdtext (original)
+++ pdfbox/cmssite/trunk/content/codingconventions.mdtext Fri May  8 19:28:04 2015
@@ -83,13 +83,13 @@ Over the years the PDFBox project has co
 
 - Give variables and methods meaningful names. Keep these short but don't use abbreviations. Prefer using the same terminology as the PDF spec.
 
-- Prefer final classes and final protected methods for non-final public classes, this reduces the surface area of the public API
+- Prefer final classes and final protected methods for non-final public classes, this reduces the surface area of the public API.
 
 - Avoid non-final protected variables in public classes. Prefer protected getters over protected variables when protected fields are necessery in public classes.
 
 - Minimize the API. Don't make everything public just because you can.
 
-- 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
+- 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.
 
 - 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.