Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

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

Closed
wants to merge 1 commit into from

3 participants

sun Paul M. Jones Miles Johnson
sun

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
Paul M. Jones
Owner

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

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

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

sun

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
Owner

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

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 php.net 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
Owner

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 http://paul-m-jones.com/archives/2420 as well as at http://www.php-fig.org/faq/ .

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/PSR-2-coding-style-guide.md
3  accepted/PSR-2-coding-style-guide.md
View
@@ -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).
[keywords]: http://php.net/manual/en/reserved.keywords.php
Something went wrong with that request. Please try again.