Skip to content

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

wants to merge 1 commit into from

3 participants

sun commented Jul 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.
@pmjones pmjones closed this Jul 25, 2012
pmjones commented Jul 25, 2012

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

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

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

sun commented Jul 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)

pmjones commented Jul 26, 2012

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 Jul 26, 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.
pmjones commented Jul 27, 2012

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
Something went wrong with that request. Please try again.