Skip to content
This repository

PSR-2 PHP constant casing contradicts PSR-1. #47

wants to merge 1 commit into from

3 participants

sun Paul M. Jones Miles Johnson
sun commented July 25, 2012

PSR-2 fails the most simple sanity check: Its guide on Boolean/Null constants contradicts PSR-1.

I'm sorry, but I fail to see how this can be "acceptable."

Two possible options:

  1. Make PSR-1 comply (lower-case [class] constants). (ugh)
  2. Fix PSR-2 to be consistent.
Paul M. Jones pmjones closed this July 25, 2012
Paul M. Jones

PSR-1 states that class constants must be upper-case. It says nothing about PHP boolean constants.

sun commented July 25, 2012
  • PSR-1 enforces class constants to be in all upper case.
  • PSR-2 enforces Boolean constants to be in all lower case.
Miles Johnson
milesj commented July 25, 2012

Null, true and false are data types, not constants. So whats the argument here?

sun commented July 25, 2012

Even the PHP manual states:

To specify a boolean literal, use the keywords TRUE or FALSE. Both are case-insensitive.

(not only on that page)

Paul M. Jones

The PSRs are derived from an accumulation of userland code, not from PHP manual examples. I get where you're coming from, but this accepted PSR is not likely to be amended in-place.

sun commented July 25, 2012

I kinda expected some "uphill" battle (definitely feels like that). ;) Thanks for taking the proposal into consideration though. :)

That said:

  1. At least the Drupal community originally built its coding standards upon the PEAR standard (like many others), and wherever it was lacking definitions/clarifications, Drupal pro-actively consulted and coordinated with the manual maintainers, in order to figure out what PHP core thinks about a particular ambiguity in their own documentation. That is, to decrease the confusion for PHP developers (of all skill-levels) and aim for consistency. AFAIK, these efforts led to a range of manual + coding standards adjustments, both on the PHP manual side, as well as Drupal (depending on the outcome of the respective coordination).
  2. Closely tying into the above, and kinda in line with my other PR on acronyms/abbreviations: It is problematic and appears to be wrong to try overrule the coding standard decisions of PHP core (which includes its manual). Any attempt to do so introduces inconsistencies between PHP core code and userland PHP code. At minimum, that conflicts with the goal of PSR adoption.
Paul M. Jones

Not to be an ass, but at this point, it's not so much "uphill battle" as "the battle is done and we're standing on the memorial site." ;-) The PSR-1 and 2 conversations are long over; the Drupal guys were part of it, along with 20+ other surveyed frameworks/libraries/etc. You can see the survey results as an appendix on PSR-2. You can read more about the process at as well as at .

Regrading acronyms/abbrevs, I suggest starting a conversation on the mailing list.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Showing 1 unique commit by 1 author.

Jul 26, 2012
sun Fixed PSR-2 PHP constant casing contradicts PSR-1. 36c6d6b
This page is out of date. Refresh to see the latest.

Showing 1 changed file with 2 additions and 1 deletion. Show diff stats Hide diff stats

  1. 3  accepted/
3  accepted/
Source Rendered
@@ -131,7 +131,8 @@ Code MUST use an indent of 4 spaces, and MUST NOT use tabs for indenting.
131 131
132 132
 PHP [keywords][] MUST be in lower case.
133 133
-The PHP constants `true`, `false`, and `null` MUST be in lower case.
+The PHP constants `TRUE`, `FALSE`, and `NULL` MUST be in upper case (see
+[PSR-1][] 4.1. Constants).
135 136
136 137
137 138

Tip: You can add notes to lines in a file. Hover to the left of a line to make a note

Something went wrong with that request. Please try again.