Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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
Comment #1
NancyDruActually, 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.
Comment #2
douggreen CreditAttribution: douggreen commentedWe 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...
Comment #3
NancyDruWell, 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.
Comment #4
douggreen CreditAttribution: douggreen commentedI 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...
Comment #5
NancyDru// $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.
Comment #6
douggreen CreditAttribution: douggreen commentedyes
Comment #7
mooffie CreditAttribution: mooffie commentedSo, 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.
Comment #8
stella CreditAttribution: stella commentedRe-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
Comment #9
NancyDruBack 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?
Comment #10
stella CreditAttribution: stella commentedThere'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
Comment #11
Morbus IffNancyDru: see also http://groups.drupal.org/node/3308.
Comment #12
stella CreditAttribution: stella commentedNancyDru: 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
Comment #13
NancyDruWell, in that case the 6.x version is broken because it doesn't flag lowercase.
Comment #14
stella CreditAttribution: stella commentedNancyDru: 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
Comment #15
webel CreditAttribution: webel commentedThe official PHP manual says:
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.
Comment #16
webel CreditAttribution: webel commentedReopened, because I want the developers to please provide a good reason for this rule. You are welcome to simply close it afterwards.
Comment #17
webel CreditAttribution: webel commentedComment #18
Morbus Iff@webel: the only justification Coder, the module, needs is that it's part of the Drupal 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.
Comment #19
Morbus IffComment #20
webel CreditAttribution: webel commentedI wrote:
I wrote:
Morbus Iff wrote:
Thanks, done, moved to Drupal core: base: 'coding standards'.
Comment #21
webel CreditAttribution: webel commentedNow 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) ?
Comment #22
bfr CreditAttribution: bfr commentedHere'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.
Comment #23
Morbus Iff@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:
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):
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
Comment #24
webel CreditAttribution: webel commentedOne 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
Comment #25
webel CreditAttribution: webel commented@Morbus Iff
I appreciate your feedback and your detailed points. You wrote:
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.
Comment #26
webel CreditAttribution: webel commented@Morbus Iff
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.
Comment #27
webel CreditAttribution: webel commentedThis is dead right:
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).
Comment #28
webel CreditAttribution: webel commentedNo 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.
Comment #29
webel CreditAttribution: webel commentedRelated. 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).
Comment #30
webel CreditAttribution: webel commentedSuggestion 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.
Comment #31
webel CreditAttribution: webel commentedNo 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.
Comment #32
webel CreditAttribution: webel commentedFair 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..
Comment #33
webel CreditAttribution: webel commentedSuggestion: 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.
Comment #34
Morbus IffRegarding #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.
Comment #35
webel CreditAttribution: webel commented@Morbus Iff
I appreciate your detailed feedback. I know that countless Drupal.org contributors offer their own time.
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:
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.
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.
Comment #36
webel CreditAttribution: webel commentedCoder 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."
Comment #37
webel CreditAttribution: webel commentedI 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.]
Comment #38
webel CreditAttribution: webel commentedI 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:
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.
Comment #39
webel CreditAttribution: webel commentedComment #40
webel CreditAttribution: webel commentedJust for the record. From PHP-FIG: PSR-2:
Comment #41
Morbus Iff@webel, see the bottom of comment 23.
Comment #42
loopy1492 CreditAttribution: loopy1492 commentedWell, 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.
Comment #43
rodrigoaguileraFor reference. You can exclude only that rule for your JS. If you have a phpcs.xml:
docroot/themes/custom/*/src/js