3.0 changelog #116
Open
3.0 changelog #116
Conversation
This file contains hidden or 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
jrfnl
reviewed
May 31, 2025
| @@ -0,0 +1,156 @@ | |||
| # Migrating from PER-CS v1.0 (PSR-12) to PER-CS v2.0 ### | |||
There was a problem hiding this comment.
Suggested change
| # Migrating from PER-CS v1.0 (PSR-12) to PER-CS v2.0 ### | |
| # Migrating from PER-CS v2.0 to PER-CS v3.0 ### |
ralflang
approved these changes
May 31, 2025
| Formatting conventions are now provided for compound types (those that include union or intersection type declarations). | ||
|
|
||
| * The `|` and `&` symbols and parentheses MUST NOT have leading or trailing spaces. | ||
| * If a type declaration is long enough to split to multiple lines, each ANDed block must be on one line, and each ORed block on its own line. |
There was a problem hiding this comment.
Suggested change
| * If a type declaration is long enough to split to multiple lines, each ANDed block must be on one line, and each ORed block on its own line. | |
| * If a type declaration is long enough to split to multiple lines, each block must be on one line, and each block on its own line. |
|
|
||
| ## [Section 2.7 - Naming](https://www.php-fig.org/per/coding-style/#27-naming) | ||
|
|
||
| PER-CS now recommends following the same naming conventions as PHP Internals for abbreviations and acronyms. Specifically, only uppercase the first character of the acronym: `XmlFormatter`, not `XMLFormatter`. |
There was a problem hiding this comment.
Suggested change
| PER-CS now recommends following the same naming conventions as PHP Internals for abbreviations and acronyms. Specifically, only uppercase the first character of the acronym: `XmlFormatter`, not `XMLFormatter`. | |
| PER-CS now recommends following the same naming conventions as PHP Internals for abbreviations and acronyms. Specifically, only uppercase the first character of the acronym: `XmlFormatter`, not `XMLFormatter`. |
|
|
||
| ## [Section 4.6 - Modifier Keywords](https://www.php-fig.org/per/coding-style/#46-modifier-keywords) | ||
|
|
||
| At least one of `readonly`, `get`-visibility, and `set`-visibility must be specified. If at least one is specified, the others may be omitted. |
There was a problem hiding this comment.
Suggested change
| At least one of `readonly`, `get`-visibility, and `set`-visibility must be specified. If at least one is specified, the others may be omitted. | |
| At least one of `readonly`, `get`-visibility, and `set`-visibility must be specified. If at least one is specified, the others may be omitted. |
|
|
||
| Formatting guidelines for property hooks are now included. | ||
|
|
||
| When using property hooks on a constructor promoted property, only single-line set hooks are allowed. Anything more complicated MUST be defined separately from the constructor. |
There was a problem hiding this comment.
Suggested change
| When using property hooks on a constructor promoted property, only single-line set hooks are allowed. Anything more complicated MUST be defined separately from the constructor. | |
| When using property hooks on a constructor promoted property, only single-line set hooks are allowed. Anything more complicated MUST be defined separately from the constructor. |
|
|
||
| ## [Section 6.4 - Operator placement](https://www.php-fig.org/per/coding-style/#64-operator-placement) | ||
|
|
||
| When breaking a series of chained operations across multiple lines, the operator MUST be at the beginning of each line, not the end of each line, and all lines but the first MUST be indented. Examples include `??` and ternary conditionals. |
There was a problem hiding this comment.
Suggested change
| When breaking a series of chained operations across multiple lines, the operator MUST be at the beginning of each line, not the end of each line, and all lines but the first MUST be indented. Examples include `??` and ternary conditionals. | |
| When breaking a series of chained operations across multiple lines, the operator MUST be at the beginning of each line, not the end of each line, and all lines but the first MUST be indented. Examples include `??` and ternary conditionals. |
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.
The links point to the live site, like the 2.0 changelog does, so not all of them will work yet. They should once it's tagged and published, though.