IIRC, we were told to use TRUE, FALSE, NULL, all uppercase, instead of true, false, null.

The only mention of this I can find now is:
"Constants should always be all-uppercase"
http://drupal.org/node/5993

But Coder doesn't flag lowercase "true", "false", "null" as errors. It this intentional?

Comments

NancyDru’s picture

Actually, if you do them in uppercase and choose the "Performance" option, you will see why. Lowercase is marginally faster than uppercase. I've pretty much switched to lowercase now.

douggreen’s picture

We could never agree on the "performance" rules and I thought that the performance review was actually dropped. Maybe there's a coding standard reason to check for caps/lower, but and don't think that we should be checking for caps or lower case values at all. Just my opinion...

NancyDru’s picture

Well, I still see the performance stuff in the latest 5.x version. IMO, it has a few problems with quotes, but it's no big deal.

Personally I feel that the all caps version can be visually distracting in that it emphasizes some things that shouldn't be, such as those in the title here. I like Sql statements using caps, but code peppered with "TRUE," "FALSE," and "NULL" can make the code less readable, IMHO. I doubt the performance hit is significant enough to worry about, especially since we're using an interpreted language to start with.

douggreen’s picture

I think that you have an old copy lying around. If you download coder from the project page, it doesn't package it because the CVS logs shows that it was DELETED on Aug 31, 2007:

http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/coder/inclu...

NancyDru’s picture

// $Id: coder.module,v 1.55.2.19.4.18 2008/01/31 20:17:43 douggreen Exp $

When I update my modules, I don't delete the old one, just unpack the new code into the same directory. I do see that coder_performance has a pretty old date on it and it's not in my 6.x version. I guess I can safely delete that? Maybe I should actually uninstall, delete the directory, and re-install Coder.

douggreen’s picture

yes

mooffie’s picture

Status: Active » Closed (won't fix)

So, let's close this.

Presonally I prefer 'true', 'false', 'null', because they look "pure", and, besides, this isn't C. But, alas, I go with uppercase for consitency.

Thank you Nancy and Doug.

stella’s picture

Re-opening this due to #283203: Use uppercase for PHP constants, e.g. NULL, TRUE, FALSE. Using uppercase TRUE, FALSE, NULL is part of the Drupal coding standards, therefore Coder should check for this. If you disagree with this coding standard, then you should put forward your case and try to get the standards changed.

NancyDru: do you have any references on the lowercase versions being faster?

Cheers,
Stella

NancyDru’s picture

Status: Closed (won't fix) » Active

Back when Coder had a performance section, this was the recommendation. Perhaps somewhere back in that feature request there was a reference.

I personally find these constants really ugly in uppercase when they are highlighted by my text editor.

Where do we start the discussion on the standards?

stella’s picture

There's no clear place that I know of. I'd create an issue and put it either in the Drupal queue or the Drupal webmasters queue. Then send an email to the dev list to see if you can get a response there. You'd want something to back up the performance claim. A pure aesthetic type reason will not benefit your argument.

Cheers,
Stella

Morbus Iff’s picture

stella’s picture

NancyDru: see Morbus' link. That's the appropriate place to post up any follow-ups you may have with references to back up your performance claim. If the coding standards are ever changed in the future, please feel free to re-open this issue. In the meantime, Drupal has coding standards, which Coder should enforce, so I'm not removing this check.

Cheers,
Stella

NancyDru’s picture

Status: Active » Closed (won't fix)

Well, in that case the 6.x version is broken because it doesn't flag lowercase.

stella’s picture

NancyDru: the 6.x version has the same check in as the 5.x version. Can you double-check that you have the latest version installed? If it's still failing, can you paste in the line of code for which it fails to alert?

Cheers,
Stella

webel’s picture

Issue summary: View changes

The official PHP manual says:

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

As far as I am concerned, enforcing CAPITAL TRUE, FALSE (and NULL) is just another Coder annoyance with little benefit. I have read a dozen discussions about it, some people claim CAPITAL TRUE is easier to read, but it requires use of the CAPS KEYS and is thus slower to type. It's not the most important thing in the world, but I can't see any good reason for enforcing one way or the other (there is no value adding to forcing people to choose).

Postscript: applying the Drupal coding standards and Coder to this object-oriented module project is soaking up many days of my time, unpaid of course, mostly with as far as I am concerned little or no benefit. The NULL, TRUE, FALSE is a perfect example. Basically, I have better things to do before I die. I vote "please kill this rule".

I appreciate the need for coding standards, but they must add benefit and not simply waste experienced developers' time.

webel’s picture

Status: Closed (won't fix) » Active

Reopened, because I want the developers to please provide a good reason for this rule. You are welcome to simply close it afterwards.

webel’s picture

Version: 5.x-2.x-dev » 7.x-2.2
Morbus Iff’s picture

@webel: the only justification Coder, the module, needs is that it's part of the Drupal Coding Standards:

Constants should always be all-uppercase, with underscores to separate words. (This includes pre-defined PHP constants like TRUE, FALSE, and NULL.)

--https://www.drupal.org/coding-standards

If you want it gone from Coder, you'd have to rally a change to the coding standards, NOT a change to the coder.module.

Morbus Iff’s picture

Status: Active » Closed (works as designed)
webel’s picture

Project: Coder » Drupal core
Version: 7.x-2.2 » 8.x-dev
Component: Coder Format » base system
Category: Support request » Task
Status: Closed (works as designed) » Active
Issue tags: +Coding standards

I wrote:

The official PHP manual says:

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

As far as I am concerned, enforcing CAPITAL TRUE, FALSE (and NULL) is just another Coder annoyance with little benefit ..

I wrote:

Reopened, because I want the developers to please provide a good reason for this rule. You are welcome to simply close it afterwards.

Morbus Iff wrote:

If you want it gone from Coder, you'd have to rally a change to the coding standards

Thanks, done, moved to Drupal core: base: 'coding standards'.

webel’s picture

Category: Task » Support request

Now as a support request inviting clear justification and explanation. In short, if PHP does not care whether one uses 'true' or 'TRUE', why should Drupal module developers ?

Where is the value add ?

Why should we invest time in changing perfectly good, functional, readable code (that is faster to write than using CAPS) ?

bfr’s picture

Here's some evidence that 'false' is faster than 'FALSE'. Is that test reliable? Who cares. The whole speed argument is nonsense. All we should care about is the readability of the code(in cases like this). Just like it does not matter(performance-wise) if we use print or echo, even though echo is marginally faster(because it does not return anything).

That said, i think both ways are readable and fast enough to write, so whichever standard we choose is ok with me.

@21
PHP does not care about indentations either, but we have these standards to keep the code consistent and, again, readable.

Morbus Iff’s picture

@webel, your current assumption is that there /is/ value-add, and that just might be the wrong way of looking at it. There are going to be people who like it one way, and there are going to be people who like it the other way, with no tangible explanation save "it feels better". Let's enter bullet-time:

  • You suggest it is "bad" because it adds a single additional keystroke (that is "holding down SHIFT as I type"). Removing that additional keystroke, for any at-speed typer, is unlikely to cause any noticeable savings in time, unless amortized over years of coding - for me, SHIFT is as ignorable as SPACE is - I rarely think about it when I'm typing. Removing SHIFT is as much a premature optimization as the unconfirmed milliseconds of speed savings for lowercase constants.
  • You've thrown a search/replace for (true/false/null) to (TRUE/FALSE/NULL) into a woe-is-me Coder aggregate of "many days of my time, unpaid of course" when an editor-provided search and replace across your much smaller codebase (than Drupal core, Symfony, Guzzle, etc., etc.) would take minutes at most. You're coming from an emotional place, but I can't help but infer that "many days of my time" means you've never really coded an up-to-code-standards project in Drupal before and, thus, your fingers haven't learned how to type in Drupal-coding-standards in the first place. The amount of "unlearning" and "shifting" required to adhere to a new project is /always/ going to take a while and almost /always/ going to cause knee-jerk, irrational, "what the hell were they thinking?!" sort of feelings.
  • You assert that "if PHP doesn't care, why should Drupal?". I'd like to rewrite that sentence to "if the PHP interpreter doesn't care, but the PHP documentation does care, why should Drupal?" As @bfr implies, the PHP interpreter doesn't care about a lot of things that we humans do, like whitespace and indenting and proper variable names. But there /is/ evidence of care by the folks behind PHP, simply due to their documentation, which always uses TRUE, FALSE, and NULL. That is a vote of caring, a vote of distinguishment. Should I expect to see a similar issue in the PHP queues to get their documentation to use true, false, and null?
  • true/false/null creates a split in the standard-y-ness of the coding standards. We've already established that constants should be capitalized. Ignoring everything else (the built-in-ness, the frequency of use, etc.), TRUE/FALSE/NULL are constants. Ignoring everything else, there should be no reason that any one constant is treated differently than any other constant. This is why there's specific mention of TRUE/FALSE/NULL in the guidelines - because even though your code works with the lowercase equivalent, you've created a difference in how constants appear and that doesn't engender itself to a "standard" approach ("do this, unless..." vs. "always do this").
  • Laziness. You're lazy. I'm lazy. This six year old issue is lazy. Almost every other developer is lazy. You're asking thousands of coders to change the way they've been doing things for six years (often unconsciously now, similar to how you probably unconsciously type "true", "false", and "null") "just because" lowly ol' you has to work a few extra minutes (not days). I'm not trying to lessen you or your importance, mind, I'm merely trying to illustrate the magnitude of the change you're requesting.

Now, I've beat on you enough, so lemme help you out. If you really wanted to argue and request this properly (and that's what you should have done, not demanded justification for why "we" clearly chose the wrong approach), I'd go something along these lines (I'll leave it to you to expand and extrapolate):

  • JavaScript uses true/false/null and Drupal uses lots of JS. Standardize!
  • Symfony uses true/false/null cos it respects PSR-2! Standardize!

And, hell, if you really wanted to get true/false/null in, you could try to push through PSR-2 support (but that doesn't seem likely):

https://www.drupal.org/node/1693672

webel’s picture

One reason i have for not liking to have to change from say '= null' to '= NULL' in default values for parameters or default values of class variables is that I have a reverse engineered UML model of my module imported into MagicDraw UML using PEAR PHP_UML to generate the XMI.

Every time I have to change to upper case NULL I have to go and change it tediously in my UML model.

Not likely a problem many of you will relate to for now, but for me it is a great inconvenience.

I am trying to train NetBeans IDE to meet the coding standards and pass Coder.

But some of the rules simply indicate, no other way to say it, than some of the people who have decided those rules are not experienced OO people. It's that simole.

I love Drupal for what it can do.

Webel

webel’s picture

@Morbus Iff

I appreciate your feedback and your detailed points. You wrote:

you've never really coded an up-to-code-standards project in Drupal before

Dead right. But it's not the first time elsewhere.

I have particular needs, I am demonstrating graphical UML modelling of an object oriented tutorial module.

I accept that not everybody will care about the same rules as I do, but I have very good reasons for those rules for managing code that is amenable to reverse engineering in PEAR: PHP_UML to XMI for import into MagicDraw UML.

webel’s picture

@Morbus Iff

you could try to push through PSR-2 support (but that doesn't seem likely):

My aim is to get my object-oriented UML friendly Drupal7 tutorial module from the sandbox to a real project as soon as possible with existing Coder, I don't have time now of that it will take time. Maybe later.

I did not actually expect you to necessarily change the rule
(although i would not mind if both lower and UPPER would be accepted),
i asked for ("demanded") an explanation and I got it.

Thanks.

webel’s picture

This is dead right:

thus, your fingers haven't learned how to type in Drupal-coding-standards in the first place.

Well, they are sure getting a lot of practice at it now.

I code a lot in Java, and my coding style is very influenced by coding agile Java for reverse engineering to UML. The recipes translate well to PHP, however they are different from your Drupal coding standards (and more Agile regarding documentation, and with special OO coding rules for UML).

webel’s picture

You're asking thousands of coders to change the way they've been doing things for six years

No I am not, if you open the rule to enable both lower and UPPER it lets more coders code pass Coder, I'm not asking anybody else to change their style at all in this case. My suggestion stops Coder tripping on many other modules written by others.

It's just a Coder rule.

webel’s picture

Related. I am aware that there is a slight inconsistency regarding use of CAPS (takes 2 CAPS keys, 1 up, 1 down) in this issue report OO: Coding standards: permit CAPITALS_WITH_UNDERSCORES for static class variables. It is however a common coding standard in the Java world (but not everywhere).

webel’s picture

Suggestion for Coder (if such already exists please refer me to docs). Strict mode and switches so users can decide for examples whether they want the strict CAPS rule for such cases, or whether they will admit either lower or UPPER.

webel’s picture

I'm merely trying to illustrate the magnitude of the change you're requesting.

No it's not, it's almost trivial.

It's a 5 second rule change or (takes a bit longer since requires Coder coding) introducing strict mode switch and policy switches.

webel’s picture

We've already established that constants should be capitalized.

Fair enough, but why then this rule in Coder: it won't let you use MY_STATIC_CONSTANT OO: Coding standards: permit CAPITALS_WITH_UNDERSCORES for static class variables..

webel’s picture

Suggestion: submit contributed Drupal modules together with a Coder configuration file (determines for example whether in strict mode or has variations on rules like NULL, FALSE, TRUE.

This has the further benefit that modules can also then be "rated" according to compatibility with the coding rules. A module that passes Coder on STRICT then has a special icon/indicator.

Morbus Iff’s picture

Regarding #28, #30, #31, and #33:

Again, this has nothing to do with Coder.

Coder is a lint to the Drupal coding standards.

Lints must blindly follow the coding standards they adhere to.

You're asking the lint to ignore a stated part of the coding standards. Not going to happen.

If you want to use true/false/null AND match the Drupal Coding Standards, you must change the Drupal Coding Standards.

Changing Coder to your liking is trivial, I agree. Changing the Drupal Coding Standards is a mUuUUUch different beast (even if that involves "merely" creating a strict vs. lazy option, something which has never historically been palatable -- see Perl's use strict and E_ALL/E_NOTICE in PHP])., and is the level of magnitude I'm talking about.

If you continue mentioning Coder, you're doing it wrong™. Coder is right.
Your beef is with the Drupal Coding Standards.

webel’s picture

@Morbus Iff

I appreciate your detailed feedback. I know that countless Drupal.org contributors offer their own time.

Coder is a lint to the Drupal coding standards.

Yes, that's what I am telling you.

I am suggesting there is an opportunity of changing that so that Coder encapsulates the rules with switches, so that it becomes and IT expression of the coding standards, but flexible, with switches to enable people to decide a level of compliance. STRICT means all rules exactly as per Drupal coding standards.

However, a set of Coder rules can never capture 100% of the freestyle Drupal docs anyway. The idea that it is "just doing what the coding standards say" is never 100% true anyway, it is always just a model of those rules.

I am saying users can choose to submit a Coder config file with their module code. You wrote:

Lints must blindly follow the coding standards they adhere to.

But they can't. It's a myth. They can only approximate those standards because there is a translation between human text, PHP code, and the rules.

If you continue mentioning Coder, you're doing it wrong™. Coder is right.
Your beef is with the Drupal Coding Standards.

No it's not, it's with both of you equally. Some of the things I am discussing are directly for Coder, such as my rules switches configs file idea. I won't list them here, but of the dozens of issues I've submitted the last weeks, I would say about half of them are directly for Coder.

My deal to the maintainers: I will do my best to submit reports to the Coding Standards team. I can then, if a suggestion is accepted, push it to Coder for implementation. By contrast, feature suggestions for Coder belong here.

webel’s picture

Coder is right.

Coder indeed does an excellent job of applying the rules and is easy to use. Congratulations, it's a good tool. However, it has clearly not been applied to object-oriented projects like mine (there are just too many giveaways, like insisting setters of method should read like this setTheThing($the_thing).

Some of the problems, for say my graphical-UML-amenable coding system, is Drupal coding standards. However, the treatment of some other matters like comments is not as exactly specified in the docs as even the Coder rules.

You ARE departing from the Drupal coding and documentation standards (which is not unexpected) because the medium in which you are representing them - PHP and sniffer rules - is different from the free text docs they are based on.

It's physically, intellectually, mentally, experimentally, impossible to make them identical.

It's like saying you can represent Eqyptian drawings in English. "Not gonna happen."

webel’s picture

I am changing all of my (null, false, true) to (NULL, FALSE, TRUE) in all my module code.

I am trying to figure out how to perform a search and replace on the UML model I have imported the PEAR PHP_UML model into. That's my own little struggle.

[EDIT: I know how to do a search and replace in the UML tool of course, I mean I have to be careful about model consistency. If there are 2 different UML elements, say 'null' and 'NULL', if they have identity, one can't just search and replace, because you'll get 2 NULL elements ! They look all like NULL, but are in fact separate elements.]

webel’s picture

I accept this issue as now closed. However, for clarification, there is something very subtle yet important about what I am doing and it is easy for others to overlook:

an editor-provided search and replace across your much smaller codebase
(than Drupal core, Symfony, Guzzle, etc., etc.) would take minutes at most.

And it took minutes with NetBeans.

You are completely missing the point for my case, I am doing graphical UML engineering of my model. If I make changes to the PHP code using NetBeans (easy enough) it impacts on my already reverse engineered UML model and on the accuracy of hundreds of graphical UML diagrams that already include lower case null, false, and true all over the place. Yes, if I had used the Drupal capital standard for NULL, TRUE, FALSE from the beginning I would have avoided that problem.

webel’s picture

Status: Active » Closed (works as designed)
webel’s picture

Just for the record. From PHP-FIG: PSR-2:

2.5. Keywords and True/False/Null
PHP keywords MUST be in lower case.

The PHP constants true, false, and null MUST be in lower case.

Morbus Iff’s picture

@webel, see the bottom of comment 23.

loopy1492’s picture

Well, right now blt validate:phpcs is flagging all of my javascript with true/false. And when I change all of the true/false in my javascript to TRUE/FALSE, I get console errors.

So now I have to add all my javascript to exclude-pattern in phpcs.xml.dist because of it.

rodrigoaguilera’s picture

For reference. You can exclude only that rule for your JS. If you have a phpcs.xml:


docroot/themes/custom/*/src/js