Add a section on short-lambdas #17
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
samdark
approved these changes
Jun 2, 2022
fruitl00p
added a commit
to fruitl00p/per-coding-style
that referenced
this pull request
Jun 23, 2022
… classes) According to chapter 4: > ## 4. Classes, Properties, and Methods > > The term "class" refers to all classes, interfaces, and traits. > > Any closing brace MUST NOT be followed by any comment or statement on the same line. > > When instantiating a new class, parentheses MUST always be present even when there are no arguments passed to the constructor. This MR updates the spec to adhere to that rule on anonymous classes too. (taken from moved from php-fig/fig-standards#1283 but also builds upon php-fig#17)
|
I'm really not a fan of that long form short closure but I don't really have any suggestions to improve it for now. |
|
I think this was a mistake. The fact that PHP-CS-Fixer previously enforced spacing after the The primary intention for arrow functions is to avoid much of the verbosity of anonymous functions, and requiring a space after the |
theodorejb
added a commit
to theodorejb/per-coding-style
that referenced
this pull request
Nov 10, 2022
Per the accepted [Arrow Functions RFC](https://wiki.php.net/rfc/arrow_functions_v2) and [per its author](https://www.reddit.com/r/PHP/comments/fctb18/comment/fjd9u6a/), short closures were intended to be written without a space after the `fn` keyword. This is how most open source projects I'm familiar with currently format them, and is also the default formatting used in PhpStorm. PHP-CS-Fixer was an outlier which incorrectly enforced spacing after the `fn` keyword using the same setting as for the `function` keyword. This was a bug and has been corrected with the addition of a separate `closure_fn_spacing` setting (though this setting still defaults to `one` for backwards compatibility - it will most likely be changed in the next major release to follow this coding style guide). The primary intention of arrow functions is to avoid much of the verbosity of anonymous functions, so requiring a space after the `fn` keyword is a step backwards from this, and also doesn't align with general usage by the community. The section on Short Closures was not added until July 17 by php-fig#17, which was after the 1.0.0 spec was approved/released on June 9, so I'm hoping it's not too late to correct it.
theodorejb
added a commit
to theodorejb/per-coding-style
that referenced
this pull request
Nov 10, 2022
Per the accepted [Arrow Functions RFC](https://wiki.php.net/rfc/arrow_functions_v2) and [per its author](https://www.reddit.com/r/PHP/comments/fctb18/comment/fjd9u6a/), short closures were intended to be written without a space after the `fn` keyword. This is how most open source projects I'm familiar with currently format them, and is also the default formatting used in PhpStorm. PHP-CS-Fixer was an outlier which incorrectly enforced spacing after the `fn` keyword using the same setting as for the `function` keyword. This was a bug and has been corrected with the addition of a separate `closure_fn_spacing` setting (though this setting still defaults to `one` for backwards compatibility - it will most likely be changed in the next major release to follow this coding style guide). The primary intention of arrow functions is to avoid much of the verbosity of anonymous functions, so requiring a space after the `fn` keyword is a step backwards from this, and also doesn't align with general usage by the community. The section on Short Closures was not added until July 17 by php-fig#17, which was after the 1.0.0 spec was approved/released on June 9, so I'm hoping it's not too late to correct it.
theodorejb
added a commit
to theodorejb/per-coding-style
that referenced
this pull request
Nov 10, 2022
Per the accepted [Arrow Functions RFC](https://wiki.php.net/rfc/arrow_functions_v2) and [per its author](https://www.reddit.com/r/PHP/comments/fctb18/comment/fjd9u6a/), short closures were intended to be written without a space after the `fn` keyword. This is also the default formatting enforced by PhpStorm. PHP-CS-Fixer was an outlier which incorrectly enforced spacing after the `fn` keyword using the same setting as for the `function` keyword. This was a bug and has been corrected with the addition of a separate `closure_fn_spacing` setting (though this setting still defaults to `one` for backwards compatibility - the intention was to [change it to enforce no space](https://github.com/PHP-CS-Fixer/PHP-CS-Fixer/blob/b577444c38b61f2fdc32cd0a4685bd595be391b7/src/Fixer/FunctionNotation/FunctionDeclarationFixer.php#L235) in the next major 4.0 version). The primary intention of arrow functions is to avoid much of the verbosity of anonymous functions, so requiring a space after the `fn` keyword is a step backwards from this, and also doesn't align with general usage promoted by PhpStorm as well as the accepted PHP RFC and documentation. The section on Short Closures was not added until July 17 by php-fig#17, which was after the 1.0.0 spec was approved/released on June 9, so I'm hoping it's not too late to correct it.
theodorejb
added a commit
to theodorejb/per-coding-style
that referenced
this pull request
Nov 10, 2022
Per the accepted [Arrow Functions RFC](https://wiki.php.net/rfc/arrow_functions_v2) and [per its author](https://www.reddit.com/r/PHP/comments/fctb18/comment/fjd9u6a/), short closures were intended to be written without a space after the `fn` keyword. This is also the default formatting enforced by PhpStorm. PHP-CS-Fixer was an outlier which incorrectly enforced spacing after the `fn` keyword using the same setting as for the `function` keyword. This was a bug and has been corrected with the addition of a separate `closure_fn_spacing` setting (though this setting still defaults to `one` for backwards compatibility - the intention was to [change it to enforce no space](https://github.com/PHP-CS-Fixer/PHP-CS-Fixer/blob/b577444c38b61f2fdc32cd0a4685bd595be391b7/src/Fixer/FunctionNotation/FunctionDeclarationFixer.php#L235) in the next major 4.0 version). The primary goal of arrow functions is to avoid the verbosity of anonymous functions, so requiring a space after the `fn` keyword is a step backwards from this, and also doesn't align with general usage promoted by PhpStorm as well as the accepted PHP RFC and documentation. The section on Short Closures was not added until the 17th of July by php-fig#17, which was after the 1.0.0 spec was approved/released on June 9, so I'm hoping it's not too late to correct it.
theodorejb
added a commit
to theodorejb/per-coding-style
that referenced
this pull request
Nov 10, 2022
Per the accepted [Arrow Functions RFC](https://wiki.php.net/rfc/arrow_functions_v2) and [per its author](https://www.reddit.com/r/PHP/comments/fctb18/comment/fjd9u6a/), short closures were intended to be written without a space after the `fn` keyword. This is also the default formatting enforced by PhpStorm. PHP-CS-Fixer was an outlier which incorrectly enforced spacing after the `fn` keyword using the same setting as for the `function` keyword. This was a bug and has been corrected with the addition of a separate `closure_fn_spacing` setting (though this setting still defaults to `one` for backwards compatibility - the plan was to [change it to enforce no space](https://github.com/PHP-CS-Fixer/PHP-CS-Fixer/blob/b577444c38b61f2fdc32cd0a4685bd595be391b7/src/Fixer/FunctionNotation/FunctionDeclarationFixer.php#L235) in the next major 4.0 version). But the current PER coding style spec may get in the way of this plan. Since the primary goal of arrow functions is to avoid the verbosity of anonymous functions, requiring a space after the `fn` keyword is a step backwards, and also doesn't align with general usage promoted by PhpStorm as well as the accepted PHP RFC and documentation. The section on Short Closures was not added until the 17th of July by php-fig#17, which was after the 1.0.0 spec was approved/released on June 9, so I'm hoping it's not too late to correct it.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I actually quite detest the extra space after the
fn, and find it hard to read and write. However, it is enforced by coding style tools now and is consistent with the long-closure form, which also requires the extra space.The rest is, I think, uncontroversial. (I hope.)