updated docs. spelling mistakes.

mainline/doc/home.html

@@ -207,21 +207,21 @@
 
           <h3>Highlights</h3>
           <p>Metrix++ is a tool to collect and analyse code metrics. Any metric is useless if it is not used.
-             Metrix++ offers great usage capabilities and assists with variety of application use cases:</p>
+             Metrix++ offers ease of introduction and integration with a variety of application use cases.</p>
           <ul>
-            <li>Monitoring trends on <strong>daily</strong> basis. In order to take actions or make right decisions earlier.</li>
-            <li>Enforcing trends on <strong>hourly</strong> basis, at every commit of code changes. In order to control quality in time, i.e. when it is not too late to redo.</li>
-            <li>Assisiting on <strong>per minute</strong> basis during code refactoring and code development, where coding and quality standards matter.</li>
+            <li>Monitoring trends (eg. on <strong>daily</strong> basis. In order to take actions or make right decisions earlier.)</li>
+            <li>Enforcing trends (eg. on <strong>hourly</strong> basis, at every commit of code changes.)</li>
+            <li>Automated asistance to review agains standards (eg. on <strong>per minute</strong> basis during code refactoring and code development.)</li>
           </ul>
 
-          <p>The workflow sections below demonstarate basic application usecases.</p>
+          <p>The workflow sections below demonstarate these basic application usecases.</p>
 
           <h3>Languages supported</h3>
           <p>The tool can parse C/C++, C# and Java source code files. The parser identifies certain regions in the code,
-             such as classes, functions, namespaces, interfaces, etc. It obviously detects comments, strings and code for preprocessor.
-             The identified regions form a tree of nested source code blocks, which are refered after and additionally scanned by metrics plugins.
-             This concept allows to attribute metrics per regions, what gives fine grained data and rich input to analysis tools.
-             The following example demonstrates regions concept.</p>
+             such as classes, functions, namespaces, interfaces, etc. It detects comments, strings and code for the preprocessor.
+             The identified regions form a tree of nested source code blocks, which are subsequently refered to and scanned by metrics plugins.
+             Thus the tool attributes metrics to regions, which provides fine grained data to analysis tools.
+             The following example demonstrates the regions concept.</p>
              
           <table class="table">
             <thead>
@@ -293,23 +293,22 @@ file: __global__: comment
           </table>
 
           <h3>Metrics</h3>
-          <p>Metrics highlighed in blue are <strong>per file</strong> metrics. Other metrics are <strong>per region</strong> metrics.
-             Region term is explained in the previous chapter.</p>
+          <p>The metrics highlighed in blue are <strong>per file</strong> metrics. The other metrics are <strong>per region</strong> metrics.</p>
           <table class="table table-bordered">
             <thead>
               <tr>
                 <th>Metric (enable option)</th>
                 <th>Brief description</th>
-                <th>Motivation</th>
+                <th>Motivation / Potential use</th>
               </tr>
             </thead>
             <tbody>
               <tr class="info">
                 <td>std.general.size</td>
                 <td>Size of a file in bytes.</td>
-                <td rowspan="4"><ul><li>Monitoring growth of source code base.</li>
+                <td rowspan="4"><ul><li>Monitoring the growth of source code base.</li>
                     <li>Normalizing other metrics.</li>
-                    <li>Preventing large files and regions (large things difficult to maintain).</li>
+                    <li>Preventing large files and regions (large things are difficult to maintain).</li>
                     <li>Predicting delivery dates by comparing
                         <a href="http://www.compaid.com/caiInternet/casestudies/kanarticle2.pdf">S-shaped code base growth / change curves</a>.</li></ul></td>
               </tr>
@@ -332,12 +331,12 @@ file: __global__: comment
                 <td>std.code.lines.preprocessor</td>
                 <td>Number of non-blank lines of preprocessor code.</td>
                 <td><ul><li>Enforcing localisation of preprocessor code in a single place.</li>
-                    <li>Encouraging usage of safer code structures instead of preprocessor.</li></ul></td>
+                    <li>Encouraging usage of safer code structures instead of the preprocessor.</li></ul></td>
               </tr>
               <tr>
                 <td>std.code.lines.comments</td>
                 <td>Number of non-blank lines of comments.</td>
-                <td><ul><li>Low number of comments may indicate about maintainability problems.</li></ul></td>
+                <td><ul><li>Low number of comments may indicate maintainability problems.</li></ul></td>
               </tr>
               <tr>
                 <td>std.code.complexity.cyclomatic</td>
@@ -368,20 +367,21 @@ class WeekClass {
                     'std.suppress.file:count'. The first is number of suppressions per region.
                     The second is the same but applies for file-scope metrics.</td>
                 <td><ul><li>Suppressing false-positives.</li>
-                    <li>Managing the amount of suppressions. Usually there are no false-positives to suppress with the right metric,
-                        but could be exceptions in specific cases. Managing suppressions is about managing exceptions.
-                        If there are many exceptional cases, maybe something is wrong with a metric or an application of a metric.</li></ul></td>
+                    <li>Managing the amount of suppressions. There should be no false-positives to suppress with the right metric,
+                        but there could be exceptions in specific cases. Managing suppressions is about managing exceptions.
+                        If there are many exceptional cases, maybe something is wrong with a metric or the application of a metric.</li></ul></td>
               </tr>
               <tr class="info">
                 <td>std.general.procerrors</td>
-                <td>Number of errors detected by Metrix++ code parser.
-                    Errors, like mismatched brackets, may result in bad identification of regions.</td>
-                <td><ul><li>Cleaning up errors to ensure reliable code scanning.</li></ul></td>
+                <td>Number of errors detected by Metrix++ code parser.</td>
+                <td><ul><li>Cleaning up errors to ensure reliable code scanning.</li>
+                	<li>Errors, like mismatched brackets, may result in bad identification of regions.</li>
+                </ul></td>
               </tr>
               <tr class="info">
                 <td>std.general.proctime</td>
                 <td>Seconds spent on processing a file.</td>
-                <td><ul><li>Monitor and profile tool's performance.</li></ul></td>
+                <td><ul><li>Monitor and profile Metrix++ tool's performance.</li></ul></td>
               </tr>
             </tbody>
           </table>
@@ -394,17 +394,17 @@ class WeekClass {
           </div>
 
           <p>In order to get the tool working, <a href="https://sourceforge.net/projects/metrixplusplus/files/latest/download">dowload the archive</a> with the latest stable version
-             and unpack it to some folder. First run of the tool will trigger the installation within the folder,
+             and unpack it to some folder. The first run of the tool will trigger the installation within the folder,
              where it was launched.</p>
 
-          <p>Corresponding checkout from the <a href="https://sourceforge.net/p/metrixplusplus/code">version control system</a> is the following:</p>
+          <p>In order to checkout the latest released version from the <a href="https://sourceforge.net/p/metrixplusplus/code">version control system</a> use this command:</p>
           <pre>svn checkout <a href="https://sourceforge.net/p/metrixplusplus/code">svn://svn.code.sf.net/p/metrixplusplus/code</a>/releases/latest Metrix++</pre>
 
           <p>In order to checkout the latest version under development, use this command:</p>
           <pre>svn checkout <a href="https://sourceforge.net/p/metrixplusplus/code">svn://svn.code.sf.net/p/metrixplusplus/code</a>/mainline Metrix++</pre>
 
           <h4>Prerequisites</h4>
-          <p>Python Runtime Environment (version 2.7.* or later, version 3.* has not been tested)</p>
+          <p>Python Runtime Environment (version 2.7.* or later. Version 3.* has not been tested)</p>
 
           <h4>License</h4>
           <p>This program is free software; you can redistribute it and/or modify it
@@ -421,14 +421,14 @@ class WeekClass {
         <div class="page-header">
           <h1>Workflow</h1>
         </div>
-        <p>The workflow and application usecases are demonstrated using source code of 
-        	<a href="http://www.boost.org/doc/libs/1_54_0/doc/html/interprocess.html">boost/interprocess</a> library.
-        	Boost versions 1.52 and 1.54 are used and refered below as 'previous' and 'current' accordingly.</p>
+        <p>The workflow and application usecases are demonstrated using source code from the 
+        	<a href="http://www.boost.org/doc/libs/1_54_0/doc/html/interprocess.html">boost/interprocess library</a>.
+        	Boost versions 1.52 and 1.54 are used and refered below as the 'previous' version and the 'current' version accordingly.</p>
         <section id="workflow_collect_section">
           <h2>Collect data</h2>
-          <p>The first obvious step is to collect the data.
+          <p>The first step is to collect the data.
              The 'collect' tool has got multiple options to enable various metrics plugins.
-             Let's collect number of lines of code and cyclomatic complexity metrics
+             Let's collect the number of lines of code and cyclomatic complexity metrics
              for the previous (1.52.0 version) boost interprocess library. Assuming that 2 versions of boost library
              are unpacked in the current working directory:</p>
           <pre>
@@ -436,17 +436,17 @@ class WeekClass {
 &gt; python "/path/to/metrix++.py" collect --std.code.lines.code --std.code.complexity.cyclomatic -- boost/interprocess
 &gt; cd ../ # return back to working directory
 </pre>
-          <p>The list of arguments after '--' enumerates paths where to read source files.
+          <p>The list of arguments after '--' enumerates the paths to read the source files.
           	As a result of execution of this command, a file metrixpp.db will be written in the current working directory.
-          	It can be redefined with help of --db-file option.</p>
-          <p>Metrix++ has got rich functionality in comparing code bases and reducing processing scope to modified or new code.
+          	It can be redefined using the --db-file option.</p>
+          <p>Metrix++ can compare code bases which reduces processing scope to the modified or new code.
           	So, let's collect the same data for the current (1.54.0 version) boost interprocess library.</p>
           <pre>
 &gt; cd boost_1_54_0
 &gt; python "/path/to/metrix++.py" collect --std.code.lines.code --std.code.complexity.cyclomatic -- boost/interprocess --db-file-prev=../boost_1_52_0/metrixpp.db
 &gt; cd ../ # return back to working directory
 </pre>
-          <p>The option --db-file-prev points out to the file with data collected in the previous step.
+          <p>The option --db-file-prev points to the file with the data collected in the previous step.
           	So, eventually it executed iterative collection. It can speed up the exectuion significantly,
           	depending on amount of changes between two version.</p>
           <p>Check other options of the collect tool by executing:</p>
@@ -590,12 +590,12 @@ class WeekClass {
 </pre>
           <h4>Reducing analysis scope</h4>
           <p>There are two ways to reduce the analysis scope for the view tool. The first is to enumerate paths of interest.
-          	For example, the following command reduces scope to 'allocators' sub-directory within the processed code.</p>
+          	For example, the following command reduces scope to the 'allocators' sub-directory within the processed code.</p>
           <pre>
 &gt; python "/path/to/metrix++.py" view --db-file=boost_1_54_0/metrixpp.db -- ./boost/interprocess/allocators
 </pre>
-          <p>The second is to specify --scope-mode option, which instructs the tool to process only modified and/or new files/regions.
-          	For example, view the summary metrics for all modified and new regions:</p>
+          <p>The second is to specify the --scope-mode option, which instructs the tool to process only modified and/or new files/regions.
+          	For example, to view the summary metrics for all modified and new regions:</p>
           <pre>
 &gt; python "/path/to/metrix++.py" view --db-file=boost_1_54_0/metrixpp.db  --db-file-prev=boost_1_52_0/metrixpp.db --scope-mode=touched
 </pre>
@@ -681,7 +681,7 @@ class WeekClass {
         <section>
           <h3>More about the viewer</h3>
           <p>The 'view' command has got an option to alter the output format. It is possible to get the same data
-          	in xml pr python disctionary formats. This can be particularly useful for integration of the tool with
+          	in xml or python dictionary formats. This can be particularly useful for integration of the tool with
           	other applications. For example, an editor may re-collect and show context based metrics when a file is saved.</p>
           <pre>
 &gt; python "/path/to/metrix++.py" view --db-file=boost_1_54_0/metrixpp.db --format=xml
@@ -693,16 +693,16 @@ class WeekClass {
         </section>
         <section id="workflow_limit_section">
           <h2>Apply thresholds</h2>
-          <p>The viewer shows (above) that there are function with quite large value of cyclomatic complexity metric.
-          	 Growth of this metric can be considered as negative trend. Metrix++ 'limit' tool offers the capability
-          	 to organise the control over trends by applying limits to metric values.
-          	 Exceeded limites are alarms in the quality management and control.</p>
+          <p>The viewer shows (above) that there are functions with quite large cyclomatic complexities.
+          	 Growth of this metric can be considered as negative trend. The Metrix++ 'limit' tool offers the capability
+          	 to manage control over trends by applying limits to metric values.
+          	 Exceeded limits could be raised as alarms by quality management and control.</p>
         </section>
         <section id="workflow_limit_hotspots_section">
           <h3>Hotspots</h3>
-          <p>Hotspots mode of the limit tool helps to identify top files/regions exceeding a metric threshold.
-          	Let's identify top 3 functions in boost interprocess library, which exceed limit of 15 points of
-          	cyclomatic complexity metric:</p>
+          <p>The hotspots mode of the limit tool helps to identify top files/regions exceeding a metric threshold.
+          	Let's identify the top 3 functions in the boost interprocess library, which exceed a limit of 15 points of
+          	cyclomatic complexity:</p>
           <pre>
 &gt; python "/path/to/metrix++.py" limit --db-file=boost_1_54_0/metrixpp.db --max-limit=std.code.complexity:cyclomatic:15 --hotspots=3
 </pre>
@@ -737,9 +737,9 @@ class WeekClass {
         </section>
         <section id="workflow_limit_control_section">
           <h3>Controlling trends</h3>
-          <p>Exit code of the 'limit' tool is equal to number of warnings printed. This allows to use the tool
-          	as a static analysis tool during software build process. In this case, non-zero exit code means
-          	that there are violations to the agreed standards and it may fail the build. So, the same command
+          <p>The exit code of the 'limit' tool is equal to the number of warnings printed. This supports use of the tool
+          	as a static analysis tool during the software build process. In this case, a non-zero exit code means
+          	that there are violations to the agreed standards and it may fail the build. The same command
           	without --hotspots option will print all regions/files exceeding the specified limit:</p>
           <pre>
 &gt; python "/path/to/metrix++.py" limit --db-file=boost_1_54_0/metrixpp.db --max-limit=std.code.complexity:cyclomatic:15
@@ -747,13 +747,13 @@ class WeekClass {
           <h4>Modes to exclude old code from the considiration</h4>
           <p>However, it is likely there are many warnings printed in this mode, especially if very old or legacy code is profiled 
           	against new metrics and coding rules. Although all warnings can be removed 
-          	by re-factoring in scope of big task force activity, it is where many tools are rejected,
+          	by re-factoring as a big task force activity, it is where many tools are rejected,
           	because it is difficult to justify the initial cost of applying and integrating them.
-          	Metrix++ 'limit' tool has got an option --warn-mode, which helps to overcome this problem.</p>
+          	The Metrix++ 'limit' tool has got an option --warn-mode, which helps to overcome this problem.</p>
           <p>--warn-mode=touched encourages re-factoring only for new and modified regions. It enables
-          	continuous refactoring. It does not matter how late the rule is applied or 
+          	continuous refactoring. It does not matter how late the rule is applied or the
           	coding standard is modified. It is possible to do it anytime with zero initial investment.
-          	For example, applying it to boost interprocess library for a changes between 1.52 and 1.54 versions
+          	For example, applying it to the boost interprocess library for a changes between 1.52 and 1.54 versions
           	results in only 6 warnings:</p>
           <pre>
 &gt; python "/path/to/metrix++.py" limit --db-file=boost_1_54_0/metrixpp.db --db-file-prev=boost_1_52_0/metrixpp.db --max-limit=std.code.complexity:cyclomatic:15 --warn-mode=touched
@@ -813,12 +813,12 @@ class WeekClass {
 	Limit          : 15.0
 	Suppressed     : False
 </pre>
-          <p>If it is challenging or not beneficial to refactor everything touched, 
+          <p>If it is challenging or of little benefit to refactor everything touched, 
           	--warn-mode=trends simplifies the control over modified regions and only makes sure
-          	that there are no regressions in modified code. In other words, a warning is printed about modified region/file
-          	only if a metric exceeds the specified limit and the value of the metric has got negative trend in modification.
+          	that there are no regressions in modified code. In other words, a warning is printed about a modified region/file
+          	only if a metric exceeds the specified limit and the value of the metric has got a negative trend due to the modification.
           	It is possible to apply it anytime with zero initial investment and almost zero on-going investment around old code.
-          	For example, applying it to boost interprocess library for a changes between 1.52 and 1.54 versions
+          	For example, applying it to the boost interprocess library for a changes between 1.52 and 1.54 versions
           	results in only 2 warnings:</p>
           <pre>
 &gt; python "/path/to/metrix++.py" limit --db-file=boost_1_54_0/metrixpp.db --db-file-prev=boost_1_52_0/metrixpp.db --max-limit=std.code.complexity:cyclomatic:15 --warn-mode=trend
@@ -842,16 +842,16 @@ class WeekClass {
 	Limit          : 15.0
 	Suppressed     : False
 </pre>
-          <p>--warn-mode=new drops control over existing code and ensures that warnings are only about new code.
-          	For example, applying it to boost interprocess library for a changes between 1.52 and 1.54 versions
-          	results in 0 warnings, so new code is totally compliant with the standard required in the example.</p>
+          <p>--warn-mode=new ignores existing code and ensures that warnings are only about new code.
+          	For example, applying it to the boost interprocess library for a changes between 1.52 and 1.54 versions
+          	results in 0 warnings, so it shows that the new code is totally compliant with the standard required in the example.</p>
           <pre>
 &gt; python "/path/to/metrix++.py" limit --db-file=boost_1_54_0/metrixpp.db --db-file-prev=boost_1_52_0/metrixpp.db --max-limit=std.code.complexity:cyclomatic:15 --warn-mode=new
 </pre>
           <h4>Suppressions</h4>
-          <p>It is possible to suppress warnings on exceptional basis. Suppressions are collected from comments in code
-             and used by the 'limit' tool to filter out unnecessary (suppressed) warnings.
-             It allows to take fine grained control over false-positive warnings, if there are.</p>
+          <p>It is possible to suppress warnings. Suppressions are collected from comments in code
+             and used by the 'limit' tool to filter out suppressed warnings.
+             It supports fine grained control over false-positive warnings, if there are any.</p>
           <p>In order to suppress a warning:</p>
           <ul>
           	<li>per region metrics: put the metrix++ instruction in the comments before the region, for example:</li>
@@ -900,24 +900,24 @@ std::string getColorName(int color_id)
 </pre>
              </ul>
           <h5>Important notice:</h5>
-             <ul><li>--std.suppress option enables collection of 2 metrics as well: 'std.suppress:count' and 
+             <ul><li>The --std.suppress option enables collection of 2 metrics as well: 'std.suppress:count' and 
                 'std.suppress.file:count'. The first is number of suppressions per region.
                 The second is the same but applies to file-scope metrics.
-                It allows to manage the amount of suppressions.
+                It supports management of the number of suppressions.
                 Usually there are no false-positives to suppress with the <strong>right</strong> metric,
-                but could be exceptions in specific cases. Managing suppressions is about managing exceptions.
-                If there are many exceptional cases, maybe something is wrong with a metric or an application of a metric.
+                but there could be exceptions in specific cases. Managing suppressions is about managing exceptions.
+                If there are many exceptional cases, maybe something is wrong with a metric or the application of a metric.
                 Two code examples about colors above do not demonstrate the technically exceptional case,
-                they likely demonstrate a case of a process exception, like "there is no time to do it proper now", or
-                a case of wrong application of a metric, like "shut up the useless tool". So, be careful.
-                The 'view' tool shows number of suppressions and its change trends on per metric basis.</li></ul>
+                they likely demonstrate a case of a process exception, like "there is no time to do it properly now", or
+                a case of the wrong application of a metric, like "shut up the useless tool". So, be careful.
+                The 'view' tool shows the number of suppressions and its change trends on a per metric basis.</li></ul>
         </section>
 
         <section id="workflow_other_section">
           <h2>Other applications</h2>
           <h3>Checking data file properties</h3>
-          <p>Metrix++ 'info' tool is helpful to check properties of a data file, like settings used to write it,  
-          	colected metrics and files processed. For example:</p>
+          <p>The Metrix++ 'info' tool is helpful to check the properties of a data file, like the settings used to write it,  
+          	collected metrics and files processed. For example:</p>
           <pre>
 &gt; python "/path/to/metrix++.py" info --db-file=boost_1_54_0/metrixpp.db
 </pre>
@@ -948,7 +948,7 @@ test_workflow.db:: info: Collected metrics:
 	...
 </pre>
           <h3>Exporting results</h3>
-          <p>Metrix++ 'export' tool exports data files to csv formated files. For example:</p>
+          <p>The Metrix++ 'export' tool exports data files to csv formated files. For example:</p>
           <pre>
 &gt; python "/path/to/metrix++.py" export --db-file=boost_1_54_0/metrixpp.db > boost_1_54_0/metrixpp.csv
 </pre>
@@ -964,8 +964,9 @@ file,region,type,modified,line start,line end,std.code.complexity:cyclomatic,std
           <p>Files with csv format can be opened by applications, like Microsoft Office Excel, with advanced analysis capabilities.
           	For example, to draw this distribution graph:</p>
           <p align="center"><img src="assets/img/piechart.png"/></p>
-          <p>It is not recommended to use export tool to implement custom post-analysis Metrix++ extensions.
-          	  The main reason is non granted backward compatibility support for csv columns. Another main reason is that
+          <p>It is not recommended to use the export tool to implement custom post-analysis Metrix++ extensions.
+          	  The main reason is that granted backward compatibility support for csv columns is not granted.
+          	  Another main reason is that
           	  exporting is relatively slow process. It is recommended to use Metrix++ extensions API instead.</p>
         </section>
         <section id="extend_section">