You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: meta.md
+38-19Lines changed: 38 additions & 19 deletions
Original file line number
Diff line number
Diff line change
@@ -26,7 +26,7 @@ To help alleviate this issue with PSR-12, we have taken a more prescriptive appr
26
26
defined the standards for new language features as they are released.
27
27
28
28
However, it is for a lack of wanting to be dictatorial that we aimed to apply PSR-2
29
-
styling, rationale and stances (Described in Section 4, Approaches) in PSR-12 instead of
29
+
styling, rationale and stances (Described in Section 5, Approaches) in PSR-12 instead of
30
30
establishing new conventions.
31
31
32
32
The same approach is applied to the current PER.
@@ -57,12 +57,31 @@ PSR-12.
57
57
It is not the intention of this PER to add entirely new coding style guidelines. It will
58
58
also not change anything stipulated in PSR-1 and PSR-12.
59
59
60
-
## 4. Approaches
60
+
## 4. Versioning
61
+
62
+
New releases of this PER are assigned version numbers in keeping with [semantic versioning](https://semver.org/). Semantic versioning is well defined when applied to software releases but has no common definition in other contexts. This PER applies the following meanings:
63
+
64
+
***Patch** versions may contain:
65
+
* Any changes that do not alter the underlying requirements of the PER, such as fixing typos, adding clarifications or other modifications with no compatibility impact.
66
+
***Minor** versions may additionally:
67
+
* Add new `MAY` or `OPTIONAL` requirements.
68
+
* Add any new requirements for PHP syntax previously unspecified in this PER.
Projects are expected to pin their own coding style guidelines to a major version of this PER, allowing for regular upgrades to minor and patch releases as they are published. When performing such upgrades, it is intended that no change to existing code is required to maintain compliance with all requirements and recommendations of the PER. This ensures new code contributions processed by an automatic formatter follow (or disregard) recommendations consistently with the existing code.
76
+
77
+
Please note this backwards compatibility promise does not extend to projects that use new PHP syntax yet to be specified in this PER. In this circumstance, a minor version may introduce new requirements that conflict with syntax usage in existing code.
78
+
79
+
## 5. Approaches
61
80
62
81
The overarching approach is to attempt to apply existing PSR-12 styling and rationale to
63
82
new functionality as opposed to establishing new conventions.
64
83
65
-
### 4.1. Strict Types Declarations
84
+
### 5.1. Strict Types Declarations
66
85
67
86
There was a discussion about whether strict types should be enforced in the standard
68
87
https://github.com/cs-extended/fig-standards/issues/7. All were in agreement we should only
@@ -71,25 +90,25 @@ to say that strict types could not be declared. The discussion was whether it sh
71
90
considered a coding style item which should be covered or whether it was out of scope, and it
72
91
was decided to be out of scope of a coding style guide.
73
92
74
-
### 4.2. Finally and Return Types Declaration Spacing
93
+
### 5.2. Finally and Return Types Declaration Spacing
75
94
76
95
Numerous options were suggested, and they can be seen
77
96
[here for return type declarations](https://gist.github.com/michaelcullum/c025f3870c9ea1dd2668#file-returntypesspacing-php) or
78
97
[here for finally blocks](https://gist.github.com/michaelcullum/c025f3870c9ea1dd2668#file-finallyblocks-php)
79
98
and the current implementation was chosen due to consistency with other parts of the standard.
80
99
81
-
### 4.3. Enforcing short form for all type keywords
100
+
### 5.3. Enforcing short form for all type keywords
which does not support long type aliases. Therefore, it makes sense to enforce primary short type forms to be used to
85
104
have uniform syntax and prevent possible confusion.
86
105
87
-
### 4.4. Public Survey
106
+
### 5.4. Public Survey
88
107
89
108
In order to settle things using data, survey was conducted and responses from 142 people
90
109
including 17 project representatives were gathered:
91
110
92
-
#### 4.4.1. PHP-FIG Representative Results
111
+
#### 5.4.1. PHP-FIG Representative Results
93
112
94
113
| Representative | Project | Compound namespaces with a depth of two or more MUST not be used | Header statement grouping and ordering | Declare statements must each be on their own line | Declare statements in PHP files containing markup | Declare statements have no spaces: `declare(strict_types=1);`| Block declare statement formatting |`new` keyword usage, parenthesis required |Return type declaration formatting |Use statement leading slashes disallowed | Block namespace declaration formatting | General operator spacing |Try, Catch, Finally formatting | Anonymous class declaration formatting | Keyword casing, only lower case | Type keywords, short form only |
0 commit comments