Skip to content


Subversion checkout URL

You can clone with
Download ZIP


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

wants to merge 1 commit into from

3 participants


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.
@pmjones pmjones closed this

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

  • PSR-1 enforces class constants to be in all upper case.
  • PSR-2 enforces Boolean constants to be in all lower case.

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


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)


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.


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.

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
Commits on Jul 25, 2012
  1. @sun
This page is out of date. Refresh to see the latest.
Showing with 2 additions and 1 deletion.
  1. +2 −1  accepted/
3  accepted/
@@ -131,7 +131,8 @@ Code MUST use an indent of 4 spaces, and MUST NOT use tabs for indenting.
PHP [keywords][] MUST be in lower case.
-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).
Something went wrong with that request. Please try again.