CONTRIBUTING: limit line length for readability

Author: jrfnl

.github/CONTRIBUTING.md

@@ -6,15 +6,18 @@ Thank you for your interest in contributing to PHP_CodeSniffer!
 
 ## Reporting Bugs
 
-Please search the [open issues](https://github.com/PHPCSStandards/PHP_CodeSniffer/issues) to see if your issue has been reported already and if so, comment in that issue if you have additional information, instead of opening a new one.
+Please search the [open issues](https://github.com/PHPCSStandards/PHP_CodeSniffer/issues) to see if your issue has been reported
+already and if so, comment in that issue if you have additional information, instead of opening a new one.
 
 Before reporting a bug, you should check what sniff an error is coming from.
 Running `phpcs` with the `-s` flag will show the name of the sniff for each error.
 
-If the error code starts with anything other than `Generic`, `MySource`, `PEAR`, `PSR1`, `PSR2`, `PSR12`, `Squiz` or `Zend`, the error is likely coming from an external PHP_CodeSniffer standard.
+If the error code starts with anything other than `Generic`, `MySource`, `PEAR`, `PSR1`, `PSR2`, `PSR12`, `Squiz` or `Zend`,
+the error is likely coming from an external PHP_CodeSniffer standard.
 **Please report bugs for externally maintained sniffs to the appropriate repository.**
 
-Bug reports containing a minimal code sample which can be used to reproduce the issue are highly appreciated as those are most easily actionable.
+Bug reports containing a minimal code sample which can be used to reproduce the issue are highly appreciated as those are most
+easily actionable.
 
 :point_right: Reports which only include a _screenshot_ of the code will be closed without hesitation as not actionable.
 
@@ -24,14 +27,17 @@ Bug reports containing a minimal code sample which can be used to reproduce the
 PHP_CodeSniffer is a developer tool and should generally not be used in a production environment.
 
 Having said that, responsible disclosure of security issues is highly appreciated.
-Issues can be reported privately to the maintainers by opening a [Security vulnerability report](https://github.com/PHPCSStandards/PHP_CodeSniffer/security/advisories/new).
+Issues can be reported privately to the maintainers by opening a
+[Security vulnerability report](https://github.com/PHPCSStandards/PHP_CodeSniffer/security/advisories/new).
 
 
 ### Support/Questions About Using PHP_CodeSniffer
 
-Please read the [documentation in the wiki](https://github.com/PHPCSStandards/PHP_CodeSniffer/wiki) before opening an issue with a support question.
+Please read the [documentation in the wiki](https://github.com/PHPCSStandards/PHP_CodeSniffer/wiki) before opening an issue
+with a support question.
 
-The [discussion forum](https://github.com/PHPCSStandards/PHP_CodeSniffer/discussions) or [StackOverflow](https://stackoverflow.com/questions/tagged/phpcodesniffer) are the appropriate places for support questions.
+The [discussion forum](https://github.com/PHPCSStandards/PHP_CodeSniffer/discussions) or
+[StackOverflow](https://stackoverflow.com/questions/tagged/phpcodesniffer) are the appropriate places for support questions.
 
 
 ## Contributing Without Writing Code
@@ -43,16 +49,19 @@ We welcome bug triage.
 Bug triage is the action of verifying a reported bug is reproducible and is actually an issue.
 This includes checking whether the bug is something which should be fixed in **_this_** repository.
 
-To find bugs which need triage, look for issues and PRs with the ["Status: triage"](https://github.com/PHPCSStandards/PHP_CodeSniffer/labels/Status%3A%20triage) label.
+To find bugs which need triage, look for issues and PRs with the
+["Status: triage"](https://github.com/PHPCSStandards/PHP_CodeSniffer/labels/Status%3A%20triage) label.
 
 #### Typical bug triage tasks:
 * Verify whether the bug is reproducible with the given information.
 * Ask for additional information if it is not.
-* If you find the issue is reported to the wrong repo, ask the reporter to report it to the correct external standard repo and suggest closing the issue.
+* If you find the issue is reported to the wrong repo, ask the reporter to report it to the correct external standard repo
+    and suggest closing the issue.
 
 Additionally, for older issues:
 * Check whether an issue still exists or has been fixed in `master` since the issue was initially reported.
-* If it has been fixed, document (in a comment) which commit/PR was responsible for fixing the issue and suggest closing the ticket.
+* If it has been fixed, document (in a comment) which commit/PR was responsible for fixing the issue
+    and suggest closing the ticket.
 
 
 ### Testing Open Pull Requests
@@ -61,22 +70,27 @@ Testing pull requests to verify they fix the issue they are supposed to fix with
 
 To get access to a PHPCS version which includes the patch from a pull request, you can:
 * Either use a git clone of the PHP_CodeSniffer repository and check out the PR.
-* Or download the PHAR file(s) for the PR, which is available from the [Test workflow](https://github.com/PHPCSStandards/PHP_CodeSniffer/actions/workflows/test.yml) as an artifact of the workflow run.
+* Or download the PHAR file(s) for the PR, which is available from the
+    [Test workflow](https://github.com/PHPCSStandards/PHP_CodeSniffer/actions/workflows/test.yml)
+    as an artifact of the workflow run.
     The PHAR files can be found on the summary page of the test workflow run for the PR.
     If the workflow has not been run (yet), the PHAR artifact may not be available (yet).
 
 #### Typical test tasks:
 * Verify that the patch solves the originally reported problem.
 * Verify that the tests added in the PR fail without the fix and pass with the fix.
 * For a fix for false negatives: verify that the correct error message(s) are thrown by the patched code.
-* Run the patched PHPCS version against real codebases to see if the fix creates any side effects (new false positives/false negatives).
+* Run the patched PHPCS version against real codebases to see if the fix creates any side effects
+    (new false positives/false negatives).
 
 
 ### Writing sniff documentation
 
-Sniffs in PHP_CodeSniffer should preferably be accompanied by documentation. There is currently still a lot of [documentation missing](https://github.com/PHPCSStandards/PHP_CodeSniffer/issues/148).
+Sniffs in PHP_CodeSniffer should preferably be accompanied by documentation. There is currently still a lot of
+[documentation missing](https://github.com/PHPCSStandards/PHP_CodeSniffer/issues/148).
 
-Sniff documentation is provided via XML files in the standard's `Docs` directory and is available to end-users via the command-line and/or can be compiled into an HTML or Markdown file.
+Sniff documentation is provided via XML files in the standard's `Docs` directory and is available to end-users
+via the command-line and/or can be compiled into an HTML or Markdown file.
 
 To see an example of some of the available documentation, run:
 ```bash
@@ -95,11 +109,13 @@ The XML files consist of several parts:
 * The `title` attribute in the `<documentation>` tag should generally reflect the name of the sniff.
 * Each XML file can contain multiple `<standard>` blocks.
 * Each `<standard>` block can be accompanied by one or more `<code_comparison>` blocks.
-* Each code comparison block should have two `<code>` blocks, the first one showing "valid" code, the second one showing "invalid" code.
+* Each code comparison block should have two `<code>` blocks, the first one showing "valid" code, the second one
+    showing "invalid" code.
 
 Some guidelines to get you started:
 * Keep it as simple as possible.
-* When a sniff shows multiple different errors/warnings, it is recommended to have a separate `<standard>` block for each error/warning.
+* When a sniff shows multiple different errors/warnings, it is recommended to have a separate `<standard>` block
+    for each error/warning.
 * The title of a "good" code sample (on the left) should start with `Valid:`.
 * The title of a "bad" code sample (on the right) should start with `Invalid:`.
 * Don't use example code which can be traced back to a specific project.
@@ -123,39 +139,52 @@ There are also tasks looking for contributions, which don't necessarily fall int
 
 #### Issues marked with "Status: waiting for opinions"
 
-Proposals for new features, proposals for (structural) changes to PHP_CodeSniffer itself or to the contributor workflow, will initially be marked with the ["Status: waiting for opinions"](https://github.com/PHPCSStandards/PHP_CodeSniffer/labels/Status%3A%20waiting%20for%20opinions) label.
+Proposals for new features, proposals for (structural) changes to PHP_CodeSniffer itself or to the contributor workflow,
+will initially be marked with the
+["Status: waiting for opinions"](https://github.com/PHPCSStandards/PHP_CodeSniffer/labels/Status%3A%20waiting%20for%20opinions)
+label.
 
 This is an open invitation for interested parties to gather their thoughts about the issue and to leave their opinion.
 
-> Kind request: If you don't have something to add to the discussion, but do want to indicate a positive or negative opinion on a topic, please add an emoji on the original post instead of leaving a comment.
+> Kind request: If you don't have something to add to the discussion, but do want to indicate a positive or negative opinion
+> on a topic, please add an emoji on the original post instead of leaving a comment.
 
 #### Issues marked with "Status: needs investigation"
 
 Sometimes an issue has been identified, but it has not yet been pinpointed what the exact cause of the problem is.
 
-Other times, like with syntax changes in PHP itself, PHP_CodeSniffer _may_, or _may not_, handle them correctly and this will need verification.
+Other times, like with syntax changes in PHP itself, PHP_CodeSniffer _may_, or _may not_, handle them correctly
+and this will need verification.
 
-Issues like these will be marked with the ["Status: needs investigation"](https://github.com/PHPCSStandards/PHP_CodeSniffer/labels/Status%3A%20needs%20investigation) and investigating those can be a good way to learn more about the source code of PHP_CodeSniffer.
+Issues like these will be marked with the
+["Status: needs investigation"](https://github.com/PHPCSStandards/PHP_CodeSniffer/labels/Status%3A%20needs%20investigation)
+and investigating those can be a good way to learn more about the source code of PHP_CodeSniffer.
 
 #### Issues marked with "Status: help wanted"
 
-If you don't know where to start, having a browse through issues marked with the ["Status: help wanted"](https://github.com/PHPCSStandards/PHP_CodeSniffer/labels/Status%3A%20help%20wanted) and/or the ["Status: good first issue"](https://github.com/PHPCSStandards/PHP_CodeSniffer/labels/Status%3A%20good%20first%20issue) labels.
+If you don't know where to start, having a browse through issues marked with the
+["Status: help wanted"](https://github.com/PHPCSStandards/PHP_CodeSniffer/labels/Status%3A%20help%20wanted) and/or the
+["Status: good first issue"](https://github.com/PHPCSStandards/PHP_CodeSniffer/labels/Status%3A%20good%20first%20issue) labels.
 
 
 ## Contributing With Code
 
 ### Requesting/Submitting New Features
 
-Ideally, start by [opening an issue](https://github.com/PHPCSStandards/PHP_CodeSniffer/issues/new/choose) to check whether the feature is something which is suitable to be included in PHP_CodeSniffer.
+Ideally, start by [opening an issue](https://github.com/PHPCSStandards/PHP_CodeSniffer/issues/new/choose) to check whether
+the feature is something which is suitable to be included in PHP_CodeSniffer.
 
 It's possible that a feature may be rejected at an early stage, and it's better to find out before you write the code.
 
-It is also good to discuss potential different implementation options ahead of time and get guidance for the preferred option from the maintainers.
+It is also good to discuss potential different implementation options ahead of time and get guidance for the preferred option
+from the maintainers.
 
-Note: There may be an issue or PR open already. If so, please join the discussion in that issue or PR instead of opening a duplicate issue/PR.
+Note: There may be an issue or PR open already. If so, please join the discussion in that issue or PR instead of opening
+a duplicate issue/PR.
 
 > Please note: Auto-fixers will only be accepted for "non-risky" sniffs.
-> If a fixer could cause parse errors or a change in the behaviour of the scanned code, the fixer will **NOT** be accepted in PHP_CodeSniffer and may be better suited to an external standard.
+> If a fixer could cause parse errors or a change in the behaviour of the scanned code, the fixer will **NOT** be accepted
+> in PHP_CodeSniffer and may be better suited to an external standard.
 
 
 ### Getting started
@@ -168,7 +197,8 @@ Note: There may be an issue or PR open already. If so, please join the discussio
 
 ### While working on a patch
 
-Please make sure your code conforms to the PHPCS coding standard, is covered by tests and that all the PHP_CodeSniffer unit tests still pass.
+Please make sure your code conforms to the PHPCS coding standard, is covered by tests and that all the PHP_CodeSniffer
+unit tests still pass.
 
 Also, please make sure your code is compatible with the PHP_CodeSniffer minimum supported PHP version, PHP 5.4.
 
@@ -178,7 +208,8 @@ To help you with this, a number of convenience scripts are available:
 * `composer cbf` will run the autofixers for code style violations.
 * `composer test` will run the unit tests.
 * `composer coverage` will run the unit tests with code coverage and show a text summary.
-* `composer coverage-local` will run the unit tests with code coverage and generate an HTML coverage report, which will be placed in a `build/coverage-html` subdirectory.
+* `composer coverage-local` will run the unit tests with code coverage and generate an HTML coverage report,
+    which will be placed in a `build/coverage-html` subdirectory.
 * `composer build` will build the phpcs.phar and phpcbf.phar files.
 
 N.B.: You can ignore any skipped tests as these are for external tools.
@@ -195,28 +226,39 @@ For example, for the sniff named `Generic.NamingConventions.ConstructorName`:
 * The sniff lives in the `src/Standards/Generic/Sniffs/NamingConventions/` directory.
 * The tests live in the `src/Standards/Generic/Tests/NamingConventions/` directory.
 * The tests consist of two files:
-    - `src/Standards/Generic/Tests/NamingConventions/ConstructorNameUnitTest.inc` which is the test _case_ file containing code for the sniff to analyse.
-    - `src/Standards/Generic/Tests/NamingConventions/ConstructorNameUnitTest.php` which is the test file, containing two methods, `getErrorList()` and `getWarningList()`, which should each return an array with as the keys the line number in the test _case_ file and as the values the number of errors or warnings which are expected on each line.
-        Only lines on which errors/warnings are expected need to be included in the lists. All other lines will automatically be set to expect no errors and no warnings.
+    - `src/Standards/Generic/Tests/NamingConventions/ConstructorNameUnitTest.inc` which is the test _case_ file containing
+       code for the sniff to analyse.
+    - `src/Standards/Generic/Tests/NamingConventions/ConstructorNameUnitTest.php` which is the test file, containing two methods,
+        `getErrorList()` and `getWarningList()`, which should each return an array with as the keys the line number
+        in the test _case_ file and as the values the number of errors or warnings which are expected on each line.
+        Only lines on which errors/warnings are expected need to be included in the lists. All other lines will automatically
+        be set to expect no errors and no warnings.
 
 #### Multiple test case files
 
-At times, one test _case_ file is not enough, for instance when the sniff needs to behave differently depending on whether or code is namespaced or not, or when a sniff needs to check something at the top of a file.
+At times, one test _case_ file is not enough, for instance when the sniff needs to behave differently depending on whether or code
+is namespaced or not, or when a sniff needs to check something at the top of a file.
 
 The test framework allows for multiple test _case_ files.
 In that case, the files should be numbered and the number should be placed between the file name and the extension.
 
-So for the above example, the `src/Standards/Generic/Tests/NamingConventions/ConstructorNameUnitTest.inc` would be renamed to `src/Standards/Generic/Tests/NamingConventions/ConstructorNameUnitTest.1.inc` and additional test case files should be numbered sequentially like `src/Standards/Generic/Tests/NamingConventions/ConstructorNameUnitTest.2.inc`, `src/Standards/Generic/Tests/NamingConventions/ConstructorNameUnitTest.3.inc` etc.
+So for the above example, the `src/Standards/Generic/Tests/NamingConventions/ConstructorNameUnitTest.inc` would be renamed to
+`src/Standards/Generic/Tests/NamingConventions/ConstructorNameUnitTest.1.inc` and additional test case files should be numbered
+sequentially like `src/Standards/Generic/Tests/NamingConventions/ConstructorNameUnitTest.2.inc`,
+`src/Standards/Generic/Tests/NamingConventions/ConstructorNameUnitTest.3.inc` etc.
 
-The `getErrorList()` and the `getWarningList()` methods will receive an optional `$testFile=''` parameter with the file name of the file being scanned - `ConstructorNameUnitTest.2.inc` - and should return the appropriate array for each file.
+The `getErrorList()` and the `getWarningList()` methods will receive an optional `$testFile=''` parameter with the file name
+of the file being scanned - `ConstructorNameUnitTest.2.inc` - and should return the appropriate array for each file.
 
 #### Testing fixers
 
 If a sniff contains errors/warnings which can be auto-fixed, these fixers should also be tested.
 
 This is done by adding a test _case_ file with an extra `.fixed` extension for each test _case_ file which expects fixes.
 
-For example, if the above `Generic.NamingConventions.ConstructorName` would contain an auto-fixer, there should be an additional `src/Standards/Generic/Tests/NamingConventions/ConstructorNameUnitTest.inc.fixed` file containing the code as it is expected to be after the fixer has run.
+For example, if the above `Generic.NamingConventions.ConstructorName` would contain an auto-fixer, there should be an
+additional `src/Standards/Generic/Tests/NamingConventions/ConstructorNameUnitTest.inc.fixed` file containing the code
+as it is expected to be after the fixer has run.
 
 The test framework will compare the actual fixes made with the expected fixes and will fail the tests if these don't match.
 
@@ -226,7 +268,8 @@ Some guidelines for submitting pull requests (PRs) and improving the chance that
 * Please keep your PR as small as possible, but no smaller than that.
     If your change is complex, make sure you add a proper commit message explaining what you have done and why.
 * Please clean up your branch before pulling your PR.
-    Small PRs using atomic, descriptive commits are hugely appreciated as it will make reviewing your changes easier for the maintainers.
+    Small PRs using atomic, descriptive commits are hugely appreciated as it will make reviewing your changes
+    easier for the maintainers.
 * Only open your PR when you've finished work on it, and you are confident that it is ready for review.
 * Please make sure your pull request passes all continuous integration checks.
     PRs which are failing their CI checks will likely be ignored by the maintainers or closed.
@@ -237,4 +280,5 @@ However, the maintainers time is also valuable and often, more scarce, so please
 
 ## Licensing
 
-By contributing code to this repository, you agree to license your code for use under the [BSD-3-Clause license](https://github.com/PHPCSStandards/PHP_CodeSniffer/blob/master/licence.txt).
+By contributing code to this repository, you agree to license your code for use under the
+[BSD-3-Clause license](https://github.com/PHPCSStandards/PHP_CodeSniffer/blob/master/licence.txt).