Php-cs-fixer: lowercase_constants: Enable different casing for true/false and null constants.

[RomanHodulak]

In the company where I work, we use lowercase true/false constants and uppercase NULL constant. Since lowercase_constants cannot differentiate between those, it is impossible for us to set proper rules.

Could you add the option to set different casing for null and true/false?

[keradus]

big :-1:
it's violating PSR-2 in general and consistency of casing those trivials

[SpacePossum]

lets see if there is a bigger community which follows this conversion, till than I'm +0

[SpacePossum]

I'm closing this as there does not seem a bigger use of this standard. This doesn't mean I'm judging the standard wrong or whatever.

However the scope of this project is to provide a way to fix PHP code to a wide used standard. Besides advocating usage of wide used standards it is also we'll have more support for maintaining code related to such standards as there is a bigger community interest in it.

You can always create a custom fixer to suit your project needs, copy-pasting the fixer, renaming it and adjust it to fix null to uppercase shouldn't be hard. If you decide to give it a try please let me know if you want me to help out with if you get stuck with it.

[RomanHodulak]

Thank you for your comments. We've discussed this and ended up changing the standard, so our code uses all these constants in lowercase 🙂

[SpacePossum]

great to hear :) thanks for reporting back!

[drupol]

I fully agree that code should use lowercase constants.

However, Drupal uses them in uppercase.
As it would be nice to use php-cs-fixer in custom Drupal module, it would be nice to be in sync with Drupal's coding standard.

So, I just submitted a PR to fix this.

[keradus]

why to customize the tool to allow for non-best-practice instead of adjusting Drupal's standards (especially when there is a tool to automate that change) ?

[drupol]

@keradus I don't have any point of view on the righteousness of using lower or upper case constants, and to be honest, I don't care if it's one or the other.
I'm mostly coding with Drupal at work and I just want to have custom code that is in sync with Drupal's coding standards.

On the other hand, I'm more than willing to push Drupal to use the proper standard, but I was not able to find anything on these constants beside PSR-2 that recommends them and as Drupal is not using PSR2, I can't say anything.

Maybe Drupal will use PSR2 one day, but in the meantime, I have to find a proper solution for my team at European Commission and all the other people that needs this.

Note: I think that having a tool that could fit the current (_uncommon_?) Drupal's standard could be a great step forward for having an up to date coding standard in Drupal (like PSR2) in the future, so, this is why I think this PR make sense.