Wiki: various grammar and spelling fixes

Author: jrfnl

wiki/About-Standards-for-PHP_CodeSniffer.md

@@ -26,14 +26,14 @@ The typical differences between project-specific rulesets and standards are:
 | Will automatically be used when no standard is provided on the command line ? | Yes                      | No                             |
 | Can have custom sniffs ?                                                      | No                       | Yes                            |
 | Can be installed ?                                                            | No                       | Yes                            |
-| Reusability by other projects ?                                               | Limited                  | Yes                            |
+| Re-usability by other projects ?                                              | Limited                  | Yes                            |
 
-For optimal reusability, it is in most cases a good idea for a standard to be in its own repository and to be maintained as a separate project.
+For optimal re-usability, it is in most cases a good idea for a standard to be in its own repository and to be maintained as a separate project.
 
 A `[.]phpcs.xml[.dist]` file and a `ruleset.xml` file can largely contain the same type of directives.
 The [Annotated ruleset](https://github.com/PHPCSStandards/PHP_CodeSniffer/wiki/Annotated-Ruleset) page contains information on all the directives you can use.
 
-Keep in mind that for a _standard_ to be optimally reusable, it should not contain project specific information, such as `<file>` directives or `<exclude-patterns>`, while a project specific `[.]phpcs.xml[.dist]` ruleset file _can_ contain that information.
+Keep in mind that for a _standard_ to be optimally re-usable, it should not contain project specific information, such as `<file>` directives or `<exclude-patterns>`, while a project specific `[.]phpcs.xml[.dist]` ruleset file _can_ contain that information.
 
 You may also find the [Customisable Sniff Properties](https://github.com/PHPCSStandards/PHP_CodeSniffer/wiki/Customisable-Sniff-Properties) page a handy reference for customisations which can be made to PHP_CodeSniffer native sniffs.
 
@@ -245,7 +245,7 @@ use PHP_CodeSniffer\Sniffs\Sniff;
 class OperatorSpacingSniff implements Sniff {...}
 ```
 
-:x: Not following the required directory structure (missing `[CategoryName]` subdirectory):
+:x: Not following the required directory structure (missing `[CategoryName]` sub-directory):
 ```php
 <?php
 // File: MyStandard/Sniffs/OperatorSpacingSniff.php

wiki/Advanced-Usage.md

@@ -242,10 +242,10 @@ $ phpcs --encoding=windows-1251 /path/to/code
 
 ## Using a Bootstrap File
 
-PHP_CodeSniffer can optionally include one or more custom bootstrap files before beginning the run. Bootstrap files are included after command line arguments and rulesets have been parsed, and right before files begin to process. These custom files may be used to perform such taks as manipulating the internal settings of PHP_CodeSniffer that are not exposed through command line arguments. Multiple bootstrap files are seperated by commas.
+PHP_CodeSniffer can optionally include one or more custom bootstrap files before beginning the run. Bootstrap files are included after command line arguments and rulesets have been parsed, and right before files begin to process. These custom files may be used to perform such tasks as manipulating the internal settings of PHP_CodeSniffer that are not exposed through command line arguments. Multiple bootstrap files are separated by commas.
 
 ```bash
-$ phpcs --bootstrap=/path/to/boostrap.1.inc,/path/to/bootstrap.2.inc /path/to/code
+$ phpcs --bootstrap=/path/to/bootstrap.1.inc,/path/to/bootstrap.2.inc /path/to/code
 ```
 
 <p align="right"><a href="#table-of-contents">back to top</a></p>
@@ -334,13 +334,13 @@ Array
 <p align="right"><a href="#table-of-contents">back to top</a></p>
 
 
-## Printing Verbose Tokeniser Output
+## Printing Verbose Tokenizer Output
 
 This feature is provided for debugging purposes only. Using this feature will dramatically increase screen output and script running time.
 
-PHP_CodeSniffer contains multiple verbosity levels. Level 2 (indicated by the command line argument `-vv`) will print all verbosity information for level 1 (file specific token and line counts with running times) as well as verbose tokeniser output.
+PHP_CodeSniffer contains multiple verbosity levels. Level 2 (indicated by the command line argument `-vv`) will print all verbosity information for level 1 (file specific token and line counts with running times) as well as verbose tokenizer output.
 
-The output of the PHP_CodeSniffer tokeniser shows the step-by-step creation of the scope map and the level map.
+The output of the PHP_CodeSniffer tokenizer shows the step-by-step creation of the scope map and the level map.
 
 ### The Scope Map
 
@@ -439,7 +439,7 @@ The level map is most commonly used to determine indentation rules (e.g., a toke
 
 This feature is provided for debugging purposes only. Using this feature will dramatically increase screen output and script running time.
 
-PHP_CodeSniffer contains multiple verbosity levels. Level 3 (indicated by the command line argument `-vvv`) will print all verbosity information for level 1 (file specific token and line counts with running times), level 2 (tokeniser output) as well as token processing output with sniff running times.
+PHP_CodeSniffer contains multiple verbosity levels. Level 3 (indicated by the command line argument `-vvv`) will print all verbosity information for level 1 (file specific token and line counts with running times), level 2 (tokenizer output) as well as token processing output with sniff running times.
 
 The token processing output is best explained with an example. For the following file:
 

wiki/Coding-Standard-Tutorial.md

@@ -128,7 +128,7 @@ final class DisallowHashCommentsSniff implements Sniff
 }
 ```
 
-By default, PHP_CodeSniffer assumes all sniffs are designed to check PHP code only. You can specify a list of tokenizers that your sniff supports, allowing it to be used wth PHP, JavaScript or CSS files, or any combination of the three. You do this by setting the `$supportedTokenizers` property in your sniff. Adding the following code to your sniff will tell PHP_CodeSniffer that it can be used to check both PHP and JavaScript code:
+By default, PHP_CodeSniffer assumes all sniffs are designed to check PHP code only. You can specify a list of tokenizers that your sniff supports, allowing it to be used with PHP, JavaScript or CSS files, or any combination of the three. You do this by setting the `$supportedTokenizers` property in your sniff. Adding the following code to your sniff will tell PHP_CodeSniffer that it can be used to check both PHP and JavaScript code:
 
 ```php
 /**

wiki/Configuration-Options.md

@@ -218,8 +218,8 @@ $ phpcs --config-set ignore_warnings_on_exit 1
 
 ## Ignoring non-auto-fixable issues when generating the exit code (PHP_CodeSniffer >= 4.0.0)
 
-By default, PHP_CodeSniffer will exit with a non-zero code if any errors or warnings are found, whethere these are auto-fixable or not.
-If you want to display non-autofixable errors and warnings to the user, but still return with a zero exit code if non-auto-fixable issues are found, you can set the `ignore_non_auto_fixable_on_exit` configuration option.
+By default, PHP_CodeSniffer will exit with a non-zero code if any errors or warnings are found, whether these are auto-fixable or not.
+If you want to display non-auto-fixable errors and warnings to the user, but still return with a zero exit code if non-auto-fixable issues are found, you can set the `ignore_non_auto_fixable_on_exit` configuration option.
 This option is typically used by automated build tools so that a `phpcbf` run can exit with `0` if it fixed all fixable issues, but there are still some non-auto-fixable issues remaining.
 
 ```bash

wiki/Customisable-Sniff-Properties.md

@@ -41,7 +41,7 @@ This sniff ensures that parameters passed to a function are used within that fun
 ```php
 public function execute(InputInterface $input, OutputInterface $output): int
 {
-    $output->writeln('Hello World!');
+    $output->writeLine('Hello World!');
 }
 ```
 
@@ -911,7 +911,7 @@ $rootNode
         ->end()
     ->end();
 ```
-If you want to allow mutli-level indenting, set the `multilevel` property to `true`. This will allow each line to be indented 1 more or 1 less level than the previous line, while still ensuring that all lines are indented at least once.
+If you want to allow multi-level indenting, set the `multilevel` property to `true`. This will allow each line to be indented 1 more or 1 less level than the previous line, while still ensuring that all lines are indented at least once.
 
 ```xml
 <rule ref="PEAR.WhiteSpace.ObjectOperatorIndent">

wiki/Reporting.md

@@ -333,14 +333,14 @@ patching file /path/to/code/file.php
 ```
 
 > [!NOTE]
-> The `*nix` `diff` command is required for generating reports in `diff` format. Windows users may need to ensure that the `diff` command is available by either installing [DiffUtils](http://gnuwin32.sourceforge.net/packages/diffutils.htm) or, if available, adding the Git `/usr/bin/` subdirectory to the Windows system `PATH`.
+> The `*nix` `diff` command is required for generating reports in `diff` format. Windows users may need to ensure that the `diff` command is available by either installing [DiffUtils](http://gnuwin32.sourceforge.net/packages/diffutils.htm) or, if available, adding the Git `/usr/bin/` sub-directory to the Windows system `PATH`.
 
 <p align="right"><a href="#table-of-contents">back to top</a></p>
 
 
 ## Printing an Emacs Report
 
-PHP_CodeSniffer can output a report in a format the compiler built into the GNU Emacs text editor can understand. This lets you use the built-in complier to run PHP_CodeSniffer on a file you are editing and navigate between errors and warnings within the file. To print an Emacs report, use the `--report=emacs` command line argument. The output will look like this:
+PHP_CodeSniffer can output a report in a format the compiler built into the GNU Emacs text editor can understand. This lets you use the built-in compiler to run PHP_CodeSniffer on a file you are editing and navigate between errors and warnings within the file. To print an Emacs report, use the `--report=emacs` command line argument. The output will look like this:
 
 ```bash
 $ phpcs --report=emacs /path/to/code
@@ -368,7 +368,7 @@ Now you can use the compile command and associated shortcuts to move between err
 
 ## Printing a Git Blame Report
 
-PHP_CodeSniffer can make use of the `git blame` command to try and determine who committed each error and warning to a Git respository. To print a Git Blame report, use the `--report=gitblame` command line argument. The output will look like this:
+PHP_CodeSniffer can make use of the `git blame` command to try and determine who committed each error and warning to a Git repository. To print a Git Blame report, use the `--report=gitblame` command line argument. The output will look like this:
 
 ```bash
 $ phpcs --report=gitblame /path/to/code
@@ -556,7 +556,7 @@ PHP_CodeSniffer can output a sniff performance report showing you which sniffs i
 When the `--colors` option is enabled, sniffs which take more than twice the average run time per sniff will be displayed in orange and sniffs with a cumulative listener run time of more than three times the average run time per sniff will display in red.
 
 > [!NOTE]
-> The Performance report will only be useful when run without using the cache as otherwise the cache functionality will interfer with accurately measuring the runtime of sniffs.
+> The Performance report will only be useful when run without using the cache as otherwise the cache functionality will interfere with accurately measuring the runtime of sniffs.
 > So make sure to always use the `--no-cache` feature when running Performance reports.
 
 > [!NOTE]

wiki/Version-3.0-Upgrade-Guide.md

@@ -280,7 +280,7 @@ public function generate(
 
 ### Supporting Concurrency
 
-PHP_CodeSniffer version 3 supports processing multiple files concurrently, so reports can no longer rely on getting file results one at a time. Reports that used to write to local member vars can no longer do so as multiple forks of the PHP_CodeSniffer process will all be writing to a different instance of the report class at the same time and these cache values will never be merged. Instead, reports need to output their cached data directly. They will later be given a chance to read in the entire cached output and generate a final clean report.
+PHP_CodeSniffer version 3 supports processing multiple files concurrently, so reports can no longer rely on getting file results one at a time. Reports that used to write to local member variables can no longer do so as multiple forks of the PHP_CodeSniffer process will all be writing to a different instance of the report class at the same time and these cache values will never be merged. Instead, reports need to output their cached data directly. They will later be given a chance to read in the entire cached output and generate a final clean report.
 
 > [!NOTE]
 > Reports that output content in a way where the order or formatting is not important do not need to worry about caching data and can continue to produce reports they way they do now. Examples of these reports include the CSV report and the XML report.

wiki/Version-4.0-Developer-Upgrade-Guide.md

@@ -24,7 +24,7 @@ There is a separate [[Upgrade Guide for Ruleset Maintainers and End-Users|Versio
 It is highly recommended to upgrade external standards and integrations as soon as you are able.
 
 Once PHP_CodeSniffer 4.0 has been released, the PHP_CodeSniffer 3.x branch will no longer receive updates, with the exception of security fixes and runtime compatibility fixes for new PHP versions.
-This "limited support" will last a maximum of one year from the date of the PHP_Codesniffer 4.0.0 release.
+This "limited support" will last a maximum of one year from the date of the PHP_CodeSniffer 4.0.0 release.
 
 > [!IMPORTANT]
 > This also means that support for new PHP syntaxes will only land in PHP_CodeSniffer 4.x and will **NOT** be backported to the 3.x branch.
@@ -36,9 +36,9 @@ There are basically two upgrade strategies:
 1. Drop support for PHP_CodeSniffer 3.x completely and adopt support for PHP_CodeSniffer 4.x.
 2. Make your package cross-version compatible with both PHP_CodeSniffer 3.x as well as 4.x.
 
-Which strategy is best suited for your project will depend on your userbase.
+Which strategy is best suited for your project will depend on your user-base.
 
-If your userbase is known to often combine multiple external standards, making the package PHPCS cross-version compatible may be preferred to allow users to upgrade as soon as possible, while still benefitting from updates to your package if they can't upgrade to PHPCS 4.x yet.
+If your user-base is known to often combine multiple external standards, making the package PHPCS cross-version compatible may be preferred to allow users to upgrade as soon as possible, while still benefiting from updates to your package if they can't upgrade to PHPCS 4.x yet.
 
 The vast majority of the below upgrade tasks will need to be executed in both cases, but there are some upgrade tasks which can only be executed once support for PHP_CodeSniffer 3.x is being dropped.
 
@@ -122,10 +122,10 @@ Type casting for sniff property values set from within a ruleset has been made m
 
 Search for sniff which have `public` properties which can be changed from within a ruleset.
 
-* If the sniff has work-arounds in place to handle non-lowercase string `'true'` or `'false'` values for boolean properties, those work-arounds can be removed.
-* If the sniff has work-arounds in place to handle (any case) string `'null'` values, those work-arounds can be removed.
+* If the sniff has workarounds in place to handle non-lowercase string `'true'` or `'false'` values for boolean properties, those workarounds can be removed.
+* If the sniff has workarounds in place to handle (any case) string `'null'` values, those workarounds can be removed.
 * If the sniff explicitly expects only string values for array elements, the sniff may need to be updated.
-* If the sniff has work-arounds in place to handle the type casting of `true`, `false` and/or `null` for array elements, those work-arounds can be removed.
+* If the sniff has workarounds in place to handle the type casting of `true`, `false` and/or `null` for array elements, those workarounds can be removed.
 
 <p align="right"><a href="#table-of-contents">back to top</a></p>
 
@@ -200,8 +200,8 @@ Typically, this may impact projects which call `new Config` consecutive times pr
 
 ##### Upgrading
 
-Typical work-arounds for the old behaviour will use `Reflection` to reset the `Config::$overriddenDefaults` property between instantiations.
-These type of work-arounds can now be removed.
+Typical workarounds for the old behaviour will use `Reflection` to reset the `Config::$overriddenDefaults` property between instantiations.
+These type of workarounds can now be removed.
 
 <p align="right"><a href="#table-of-contents">back to top</a></p>
 
@@ -276,7 +276,7 @@ The following tokens have been removed:
 
 If these tokens are used in PHP-only sniffs, they can be safely removed.
 If these tokens are used in JS/CSS only sniffs, as mentioned in ["Support for JS/CSS has been removed"](#support-for-jscss-has-been-removed): deprecate or remove the sniff.
-If these tokens are used in mixed sniffs, which also scan PHP files, remove the CSS/JS specific code or, for cross-version compatibility, check for the existance of the tokens before using them.
+If these tokens are used in mixed sniffs, which also scan PHP files, remove the CSS/JS specific code or, for cross-version compatibility, check for the existence of the tokens before using them.
 
 <p align="right"><a href="#table-of-contents">back to top</a></p>
 
@@ -338,7 +338,7 @@ This re-tokenization has now been removed.
 
 ##### Upgrading
 
-* Search your sniffs/code for `T_INSTANCEOF` and `'static'` to find any potential work-arounds in place for the old tokenization. Those can now be removed.
+* Search your sniffs/code for `T_INSTANCEOF` and `'static'` to find any potential workarounds in place for the old tokenization. Those can now be removed.
 
 <p align="right"><a href="#table-of-contents">back to top</a></p>
 
@@ -535,9 +535,9 @@ The Ruleset class now respects sniff selection via `--sniffs=...`, even when in
 
 **Upgrading**
 
-If your own test framework contained work-arounds to get round the previous restriction, it should now be safe to remove those work-arounds and to use the `--sniffs=...` argument when initiating the `Config` class.
+If your own test framework contained workarounds to get round the previous restriction, it should now be safe to remove those workarounds and to use the `--sniffs=...` argument when initiating the `Config` class.
 
-Typically, these type of work-around can be found by searching for calls to the `Ruleset::registerSniffs()` method.
+Typically, these type of workarounds can be found by searching for calls to the `Ruleset::registerSniffs()` method.
 
 <p align="right"><a href="#table-of-contents">back to top</a></p>