pdepend · manuelpichler · Nov 22, 2016 · Feb 6, 2016
diff --git a/src/site/rst/documentation/handbook/configuration/index.rst b/src/site/rst/documentation/handbook/configuration/index.rst
@@ -43,7 +43,7 @@ Image Convert
 The ``<image-convert>`` element is a container for all configuration settings
 available for the image convert component. It is used by PHP_Depend to render
 the different graphical reports like the `Overview Pyramid`__ or the the
-*Abstraction & Instabilit* chart. ::
+*Abstraction & Instability* chart. ::
 
   <?xml version="1.0" ?>
   <symfony:container xmlns:symfony="http://symfony.com/schema/dic/services"
@@ -197,7 +197,7 @@ History
 The command line option to specify a xml configuration file already exists
 for a long time in PHP_Depend, but the configuration file wasn't really in
 use until version 0.10.0. Since this release we have started to provide an
-`XML-Schema`__ for the configuration fike and we moved several command line
+`XML-Schema`__ for the configuration file and we moved several command line
 options or previously hard-coded-switches into the xml configuration file.
 
 Starting with 2.0 the format was changed to allow integration in the

diff --git a/src/site/rst/documentation/handbook/installation/parts/github-abstract.rst b/src/site/rst/documentation/handbook/installation/parts/github-abstract.rst
@@ -1,4 +1,4 @@
-If you like to participate on the social coding plattform `GitHub`__, you can
+If you like to participate on the social coding platform `GitHub`__, you can
 use `PHP_Depend's`__ GitHub mirror to fork and contribute to the project.
 
 .. class:: shell

diff --git a/src/site/rst/documentation/handbook/introduction/parts/introduction.rst b/src/site/rst/documentation/handbook/introduction/parts/introduction.rst
@@ -43,7 +43,7 @@ task like building source statistics? The answer is easy.
   facts of a given source base. 
 * PHP_Depend scales with growing source bases, where human code
   reviews will fail at some day.
-* PHP_Depend allows you to indentify suspect parts in a software
+* PHP_Depend allows you to identify suspect parts in a software
   system that should be part of a code review, without looking into
   the source.
 * PHP_Depend also supports some fancy metrics that will become very

diff --git a/src/site/rst/documentation/handbook/reports/parts/a-i-chart.rst b/src/site/rst/documentation/handbook/reports/parts/a-i-chart.rst
@@ -74,7 +74,7 @@ close to the *Main sequence* we have a fifth metric, the package distance
 
 .. [#ubmoodqm] http://www.objectmentor.com/resources/articles/oodmetrc.pdf
 
-  *OO Design Quality Metrics - An Analysis of Dependencies*; Robert C. Matrin;
+  *OO Design Quality Metrics - An Analysis of Dependencies*; Robert C. Martin;
   1994
 
 __ http://objectmentor.com
diff --git a/src/site/rst/documentation/handbook/reports/parts/overview-pyramid.rst b/src/site/rst/documentation/handbook/reports/parts/overview-pyramid.rst
@@ -164,7 +164,7 @@ The benefit of the Overview Pyramid
 Of course, the final question is, which advantages offers the Overview
 Pyramid?
 
-The Overview Pyramid provides a simple and size indipendent way to get a
+The Overview Pyramid provides a simple and size independent way to get a
 first impression of a software system, and this without an expensive source
 code analysis. Thus the Overview Pyramid is an effective tool for a first
 cost estimate for an unknown system. With the help of this tool and know-how,
@@ -180,7 +180,7 @@ be a good help during the planning phase of a new project.
 
 .. [#cabeccn] http://www.literateprogramming.com/mccabe.pdf
 
-  IEEE Transactions on Software Enginerring; *A Complexity Measure*;
+  IEEE Transactions on Software Engineering; *A Complexity Measure*;
   Thomas J. McCabe; 1976
 
 __ /documentation/software-metrics/cyclomatic-complexity.html
diff --git a/src/site/rst/documentation/software-metrics/index.rst b/src/site/rst/documentation/software-metrics/index.rst
@@ -20,8 +20,8 @@ of an application's code base.
 +========+============================================+=========+=========+======+=======+========+
 | ahh    | *Average Hierarchy Height*                 | X       |         |      |       |        |
 |        |                                            |         |         |      |       |        |
-|        | The average of the maximum lenght from a   |         |         |      |       |        |
-|        | root class to ist deepest subclass         |         |         |      |       |        |
+|        | The average of the maximum length from a   |         |         |      |       |        |
+|        | root class to its deepest subclass         |         |         |      |       |        |
 |        | subclass                                   |         |         |      |       |        |
 +--------+--------------------------------------------+---------+---------+------+-------+--------+
 | andc   | *Average Number of Derived Classes*        | X       |         |      |       |        |
@@ -62,7 +62,7 @@ of an application's code base.
 |        | Measures the size of the interface from    |         |         |      |       |        |
 |        | other parts of the system to a class.      |         |         |      |       |        |
 +--------+--------------------------------------------+---------+---------+------+-------+--------+
-| cloc   | *Comment Lines fo Code*                    | X       |         | X    | X     | X      |
+| cloc   | *Comment Lines of Code*                    | X       |         | X    | X     | X      |
 +--------+--------------------------------------------+---------+---------+------+-------+--------+
 | clsa   | *Number of Abstract Classes*               | X       |         |      |       |        |
 +--------+--------------------------------------------+---------+---------+------+-------+--------+

diff --git a/src/site/rst/documentation/software-metrics/parts/afferent-coupling.rst b/src/site/rst/documentation/software-metrics/parts/afferent-coupling.rst
@@ -3,10 +3,10 @@
 :Description:  This article describes the Object-Oriented software metric CA -
                Afferent Coupling. It can be used to measure the responsibility
                of a component, package, class or method within a software 
-               system. The content of this article is based on UncleBob's
                whitepaper "OO Design Quality Metrics - An Analysis of 
+               system. The content of this article is based on Uncle Bob's
                Dependencies", published 1994.
-:Keywords:     CA, Afferent Coupling, UncleBob, Robert C. Martin, Class Coupling, Package Coupling, Responsibility, Testing
+:Keywords:     CA, Afferent Coupling, Uncle Bob, Robert C. Martin, Class Coupling, Package Coupling, Responsibility, Testing
 
 The *Afferent Coupling* or *CA* metric describes the number of unique 
 incoming dependencies into a software artifact. An artifact can be
@@ -18,7 +18,7 @@ the artifact's responsibility.
 
 Normally responsibility isn't a bad thing in a software system. Good 
 examples are core packages and components, like error and exception 
-handling, or the used unit testing framework. All these lowlevel 
+handling, or the used unit testing framework. All these low level 
 components have usually a very high *Afferent Coupling*, because they
 are utilized by the several parts of the software. On the other hand
 these components will rarely be changed during the lifetime of an 
@@ -28,7 +28,7 @@ have a really good test coverage for components with a high *Afferent
 Coupling* and to monitor all changes to these components carefully.
 
 A detailed description of the *CA* metric and it's impact on the stability 
-of a software system can be found in UncleBob's whitepaper "OO Design Quality
+of a software system can be found in Uncle Bob's whitepaper "OO Design Quality
 Metrics - An Analysis of Dependencies" [#ubdqm]_.
 
 Thresholds
@@ -45,7 +45,7 @@ See also
 --------
 
 - `Coupling Between Objects`__: *Coupling Between Objects* or *CBO* is the
-  oposite coupling metric for a software artifact.
+  opposite coupling metric for a software artifact.
 
 - `Efferent Coupling`__: The *Efferent Coupling* or *CE* is a software metric
   that describes the reverse perspective on dependencies.

diff --git a/src/site/rst/documentation/software-metrics/parts/class-interface-size.rst b/src/site/rst/documentation/software-metrics/parts/class-interface-size.rst
@@ -1,17 +1,17 @@
 :Author:       Manuel Pichler
 :Copyright:    All rights reserved
 :Description:  This article describes the CIS - Class Interface Size metric in
-               general. This metric was orginally defined in the Quality Model of
+               general. This metric was originally defined in the Quality Model of
                Object-Oriented Design by Bansiya & Davis. This metric is a good
-               indicator for the choosen software design and how reusable components
+               indicator for the chosen software design and how reusable components
                are implemented.
 :Keywords:     CIS, Class Interface Size, QMOOD, Quality Metrics of Object-Oriented Design, Bansiya & Davis, reusability, functionality
 
 The *Class Interface Size* or *CIS* metric is measure of the public services 
-that a class provides. This metric was orginally defined in the *QMOOD* model
+that a class provides. This metric was originally defined in the *QMOOD* model
 [#moodcis]_ by Bansiya & Davis.
 
-The orginal version of the *CIS* metric was defined as the number of public
+The original version of the *CIS* metric was defined as the number of public
 methods that a class provides. Each of these methods can be seen as a service
 where surrounding application can send messages to or receive messages from
 a class.
@@ -27,7 +27,7 @@ information between a class and the surrounding application.
 PHP_Depend uses the second variant and counts all public methods and attributes
 declared in a class to calculate its *Class Interface Size* metric.
 
-This metric is a good indicator for the choosen software design. Several 
+This metric is a good indicator for the chosen software design. Several 
 classes with a high *CIS* value are a sure sign that the design of the
 analyzed software prefers composition over inheritance to share common
 functionality between different components. So in most cases a high value is
@@ -39,8 +39,8 @@ Thresholds
 ----------
 
 It is not easy to define good thresholds for this metric, because those values
-heavy depend on the choosen design, e.g. inheritance or composition. But in
-generall we can say that is best practice to limit the public interface that
+heavy depend on the chosen design, e.g. inheritance or composition. But in
+general we can say that is best practice to limit the public interface that
 can be used to alter the internal state of an object. Therefore we suggest 20
 as a reference point for the upper limit.
 
@@ -49,5 +49,5 @@ Bibliography
 
 .. [#moodcis] http://www.ptidej.net/teaching/inf6306/fall09/notes/course4/Bansiya02-QualityModel.pdf
 
-  IEEE Transactions on Software Enginerring; *Hierarchical Model for Object-Oriented
+  IEEE Transactions on Software Engineering; *Hierarchical Model for Object-Oriented
   Design Quality Assessment*; Bansiya & Davis; 2002
diff --git a/src/site/rst/documentation/software-metrics/parts/class-size.rst b/src/site/rst/documentation/software-metrics/parts/class-size.rst
@@ -4,7 +4,7 @@
                in the literature and how it is implemented in PHP_Depend. Later in
                this article we describe the impact of the class size on several
                quality-factors in a software system.
-:Keywords:     CSZ, CS, Class Size, Khaled et al., Optiomal Class Size, SRP, Single Responsibility Principle, testability, responsibility, maintainability
+:Keywords:     CSZ, CS, Class Size, Khaled et al., Optimal Class Size, SRP, Single Responsibility Principle, testability, responsibility, maintainability
 
 The *Class Size* or *CSZ* metric is a another measure for the complexity and
 size of a class. In many publications and books this metric is frequently
@@ -18,7 +18,7 @@ number of statements, respectively the *Logical Lines Of Code* (*LLOC*), to
 measure the size of class. The second variant uses the *Lines Of Code* (*LOC*)
 as an indicator for the class size.
 
-The third variant uses two language constructs of object-oriented progamming
+The third variant uses two language constructs of object-oriented programming
 languages to measure the size of class and calculates the sum of both values.
 These to language constructs are methods and attributes, so that the existing
 metrics *Number Of Methods* (*NOM*) and *Number Of Attributes* (*VARS*) can 
@@ -29,11 +29,11 @@ be reused to calculate the *Class Size*.
 PHP_Depend implements this third variant of *Class Size* metric algorithm to
 measure the size of a class.
 
-As several researches and studies on procedual software projects have shown,
+As several researches and studies on procedural software projects have shown,
 the optimal size of a software component, lies somewhere between too small
 and too large, to be less fault-prone. This model can be visualized with an
 u-curve, where the lower arc of the U represents the optimal size of a
-component. But this model does not apply to object-orientend software systems,
+component. But this model does not apply to object-oriented software systems,
 as Khaled et al. have shown in their paper [#ooocsz]_. Object-oriented systems
 tend to be more fault-prone when they get bigger and less fault-prone when
 they use small classes and follow the Single Responsibility Principle (SRP)
@@ -57,7 +57,7 @@ Bibliography
 
 .. [#ooocsz] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.94.7296&rep=rep1&type=pdf
 
-  IEEE Transactions on Softare Engineering; The Optimal Class Size for
+  IEEE Transactions on Software Engineering; The Optimal Class Size for
   Object-Oriented Software; Khaled, Benlarbi, Nishith & Shesh; 2002
 
 .. [#poodsrp] http://www.objectmentor.com/resources/articles/srp.pdf

diff --git a/src/site/rst/documentation/software-metrics/parts/coupling-between-objects.rst b/src/site/rst/documentation/software-metrics/parts/coupling-between-objects.rst
@@ -23,7 +23,7 @@ of a software the inter coupling between different classes should be kept to a
 minimum. Beside reusability a high coupling has a second drawback, a class that
 is coupled to other classes is sensitive to changes in that classes and as a 
 result it becomes more difficult to maintain and gets more error-prone.
-Additionally it is harder to test a heavly coupled class in isolation and it is
+Additionally it is harder to test a heavily coupled class in isolation and it is
 harder to understand such a class. Therefore you should keep the number of
 dependencies at a minimum.
 
@@ -39,7 +39,7 @@ See also
 --------
 
 - `Efferent Coupling`__: *Efferent Coupling* or *CE* is a different name for
-  the same metric, that is frequently used in the literatur.
+  the same metric, that is frequently used in the literature.
 
 - `Afferent Coupling`__: The *Afferent Coupling* or *CA* is a metric that
   calculates the reverse coupling of a class.

diff --git a/src/site/rst/documentation/software-metrics/parts/cyclomatic-complexity.rst b/src/site/rst/documentation/software-metrics/parts/cyclomatic-complexity.rst
@@ -18,21 +18,21 @@ existing source code.
 A look at this list of statements may result in the questions:
 Is this list wrong, it doesn't list ``else`` and ``default``?
 But it is correct. The assumption is that both statements
-will contain the defaut execution path of a program which 
+will contain the default execution path of a program which 
 also exists when there are no special cases to capture.
 
 Each decision path gets the value *1* and the sum of all these
 values represents the Cyclomatic Complexity of the analyzed
 software fragment. Note that each function and method also 
-counts with a value of *1* With this knowlegde we can now 
+counts with a value of *1* With this knowledge we can now 
 calculate the complexity of the following example code: ::
 
   <?php                                 
   //                                                         | CCN
   // -------------------------------------------------------------
   class CyclomaticComplexityNumber                        // |  0
   {                                                       // |  0
-      public function exampe( $x, $y )                    // |  1
+      public function example( $x, $y )                   // |  1
       {                                                   // |  0
           if ( $x > 23 || $y < 42 )                       // |  1
           {                                               // |  0
@@ -71,7 +71,7 @@ and Checkstyle report it as Cyclomatic Complexity of an
 analyzed software fragment.
 
 Now we get a complexity value of *8* when we apply the CCN2 
-to the previous example, what is a growt of the software's 
+to the previous example, what is a growth of the software's 
 complexity of 60%.
 
 Due to the fact that Cyclomatic Complexity Number was 
@@ -125,7 +125,7 @@ metric?
 Mostly the complex parts of an application contain business
 critical logic. But this complexity has negative impacts on 
 the readability and understandability of source code. Those
-parts will normally become a maintainence and bug fixing
+parts will normally become a maintenance and bug fixing
 nightmare, because no one knows all the constraints, side
 effects and what's exactly going on in that part of the 
 software. This situation results in the well known saying
@@ -209,8 +209,8 @@ was going on in this method. ::
 The first thing to do is to make sure that the test suite 
 is good enough to ensure that the required refactorings 
 will not change the public behavior of the component or
-class. When this is donw and we are sure our that api
-breaks will be detected by the test suitewe can start to
+class. When this is done and we are sure our that api
+breaks will be detected by the test suite we can start to
 extract logic into separate methods.
 
 The following example shows the result of the refactoring: ::
@@ -253,5 +253,5 @@ Number of *5* is much easier to read and understand.
 
 .. [#cabeccn] http://www.literateprogramming.com/mccabe.pdf
 
-  IEEE Transactions on Software Enginerring; *A Complexity Measure*;
+  IEEE Transactions on Software Engineering; *A Complexity Measure*;
   Thomas J. McCabe; 1976
diff --git a/src/site/rst/documentation/software-metrics/parts/efferent-coupling.rst b/src/site/rst/documentation/software-metrics/parts/efferent-coupling.rst
@@ -3,9 +3,9 @@
 :Description:  This article describes the CE - Efferent Coupling metric that
                describes the dependencies a software artifact has onto other
                artifacts in the same software system. The content of this
-               article is based on UncleBob's whitepaper "OO Design Quality
+               article is based on Uncle Bob's whitepaper "OO Design Quality
                Metrics - An Analysis of Dependencies".
-:Keywords:     CE, Efferent Coupling, UncleBob, Robert C. Martin, Class Coupling, Package Coupling, Maintainability, Testing, Stability
+:Keywords:     CE, Efferent Coupling, Uncle Bob, Robert C. Martin, Class Coupling, Package Coupling, Maintainability, Testing, Stability
 
 The *Efferent Coupling* or *CE* counts the number of software artifacts a
 software entity depends on. Therefore it takes all artifacts the entity 
@@ -17,7 +17,7 @@ a first glance. But what does a high *Efferent Coupling* value mean beside
 code reuse? It means that a component depends on several other implementation
 details and this makes the component itself instable, because an incompatible
 change between two versions or a switch to a different library will/may break
-the component. Therefore it is good pratice to keep the *Efferent Coupling* 
+the component. Therefore it is good practice to keep the *Efferent Coupling* 
 for all artifacts at a minimum.
 
 A good example for such an everything breaking change is normally the switch
@@ -26,30 +26,30 @@ many dependencies between the concrete application code and different packages
 in the library code, that a switch from product *A* to product *B* will break
 several parts in the application. Therefore it is best practice to monitor the
 *Efferent Coupling* and to refactor all those artifacts where the value is
-extremly high. A good solution to high *Efferent Coupling* is the introduction
+extremely high. A good solution to high *Efferent Coupling* is the introduction
 of additional abstraction. For the given example this would mean, that you add
 an additional package which abstracts the concrete product vendor and then you
 derive concrete implementations from this abstract package.
 
 A detailed description of the *CE* metric, it's impact on the stability of a
 software system and the introduction of more abstraction can be found in 
-UncleBob's whitepaper "OO Design Quality Metrics - An Analysis of
+Uncle Bob's whitepaper "OO Design Quality Metrics - An Analysis of
 Dependencies" [#ubdqm]_.
 
 Thresholds
 ----------
 
 It is really hard to give a threshold for the *Efferent Coupling* metric and
 the only answer can be **It depends**. Normally you should try to keep the 
-*Efferent Coupling* at a minimum, and the more abstract and lowlevel a
+*Efferent Coupling* at a minimum, and the more abstract and low level a
 component is, the less the value should be.
 
 See also
 --------
 
 - `Coupling Between Objects`__: *Coupling Between Objects* or *CBO* is a 
   different name for the same metric, that is frequently used in the
-  literatur.
+  literature.
 
 - `Afferent Coupling`__: The *Afferent Coupling* or *CA* is a metric that
   calculates the reverse coupling of a class.