Explained in full under Coder issue report at: #2303963: Allow camelCase for variable naming conventions.

Summary

Typically - and in full compliance with the Drupal object-oriented naming conventions - class variables are lower $camelCase, and may offer a Java-style getter/setter pair, with the setter like public function setCamelCase($camelCase).

Coder is complaining incorrectly about OO-style setters like this:

class DefaultMenuItem extends .. implements .. {
  private $accessArguments;


  public function setAccessArguments(array $accessArguments) {
..
  }

 private $pageArguments;;

 public function setPageArguments(array $pageArguments) {
..
 }
}


88 | ERROR | Variable "pageArguments" is camel caps format. do not use mixed
| | case (camelCase), use lower case and _


105 | ERROR | Variable "accessArguments" is camel caps format. do not use
| | mixed case (camelCase), use lower case and _

It is perfectly valid, consistent, and desirable for the argument/parameter to be like $accessArguments or $pageArguments.

This matter has become an incredible annoyance and time waster in my attempts to promote a move to robust UML-friendlier object-oriented PHP for contributed Drupal modules, as demonstrated under my object-oriented educational tutorial modules OOE = Object-Oriented Examples and Flag Plus.

Please attend to it with priority, the current coding standard is indefensible, and I can't understand how anybody else can even be developing OO code for Drupal if they are using Coder without being as utterly annoyed by it as I am.

Under the related Coder issue klausi wrote:

.. we are not going to change anything in Coder until the Coding Standards are changed.

So please change the current statement of the coding standard for OOP cases, as it clearly should not apply in the case of Class setters.

And please do not try to defend this current standard by reference to any Drupal core code; I don't consider Drupal7/8 core any authority whatsoever in the matter of OOP. The question is what works well for OOP, what has been done in Java for decades, and what looks right to intelligent people, and how to stop annoying people who are trying to make a contribution to the move to mature object-orientation but are being held up by nonsense.

CommentFileSizeAuthor
#5 Drupal setter lower_case arg standard.png78.01 KBwebel
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Crell’s picture

Crell CreditAttribution: Crell at Palantir.net commented

webel: While there are good cases to be made for changing the coding standards, you're not making them.

1) "What looks right to intelligent people", aka, "if you disagree with me you're not intelligent". That's not going to encourage anyone to listen to you.
2) "What has been done in Java for decades". Java is not PHP, and PHP is not Java. While PHP's OOP implementation initially borrowed very heavily from Java's they have different evolutionary histories. Also, Java is not the be all end all of OOP (much as some Java adherents who learned nothing else in school may think otherwise). It's not even the be all end all of classic OOP (ie, uses classes).
3) UML, AFAIK, has nothing to do with this. UML doesn't care about letter casing.

The argument you want to make is around consistency and cognitive load, not around "Do it like Java does it or you're stupid". I assure you, no one will respond well to the latter approach.

Also, given where we are in the dev cycle I can say with certainty that the coding standards will NOT change before 8.0.0 is released, as it would be far too disruptive to do so. It's also very unlikely that a standard this basic would change mid-cycle, so the earliest this could change, for better or worse, would be when 9.x is opened for development (which is still quite a ways away). I'd encourage you to get used to the current standard, because even if you did get everyone on board to change it, it wouldn't happen for some years yet.

webel’s picture

webel CreditAttribution: webel as a volunteer commented

"What has been done in Java for decades". Java is not PHP, and PHP is not Java.
While PHP's OOP implementation initially borrowed
very heavily from Java's they have different evolutionary histories.

Which is not to say that any PHP-based system should adopt silly standards (and it is very silly).

Besides, it is not about PHP as a language, it is about how Drupal chooses to use PHP. Drupal here is choosing a standard than is based on a non-OO legacy, and you are missing the chance during this migration to OO to adopt a more OO friendly pattern.

> UML, AFAIK, has nothing to do with this. UML doesn't care about letter casing.

I am working on PHP code generation from UML models (including for Drupal). There is a natural pattern between a lowerCase operation argument, a matching lowerCase private variable. Your current standard runs against that pattern. (And it just plain looks ridiculous in UML or in PHP code.)

> I'd encourage you to get used to the current standard, because even if you did get everyone on board to change it, it wouldn't happen for some years yet.

There are many good things about Drupal and the Drupal working groups.

The way your are justifying keeping something so completely ridiculous is not one of them.

webel’s picture

webel CreditAttribution: webel as a volunteer commented

I, Darren Kelly, of Webel IT Australia, will never, under any circumstances, adopt this current coding standard, recommend it to anybody, do anything to make any of my colleagues think it is an ok coding standard, teach it to anybody, or take any action to encourage anybody in the Drupal community to use it, nor care at all whether any of my contributed (or custom) modules are rejected or otherwise marked as "not the Drupal way" for not using it.

And I will not wait years for the coding standard team to get a clue and fix it.

webel’s picture

webel CreditAttribution: webel as a volunteer commented

It is not fair to not grant Drupal users full Contributed Project rights because of such standards

There are roughly speaking 2 kinds of Drupal Users; those who made it through the Project Application circus earlier, and those who have not yet and are being told they "should" adhere to the coding standards.

I have for example a non-compliant yet incredibly consistent project application that has been held up for about one year (although I have worked with Drupal already for about 8 years and created many custom modules for my work, I have only relatively recently worked on contributed modules, and it has turned out to be unnecessarily exhausting and time consuming largely because of wrangling with your standards).

Now those people who have already made it through the Project Application circus in fact have, and continue to create, contributed modules that clearly ignore coding standards like this one, and get away with it.

@crell Please read carefully: I know through direct email communication with one of the major members of the TWG involved with the coding standards that that person also disagrees with this coding standard, and chooses to simply ignore the output generated by Coder (which is downstream from coding standards like this).

it is not fair; people applying for Project Applications rights should not be told they have to (or even should) adopt such coding standards - even when they are creating exemplary and innovative modules that commit the crime of being more consistent that this standard - in order to get full Project rights, when in fact there are many old-timer Drupal contributors who in regularly do not meet the coding standards, and are not required to, because they already have full Project rights, and got them without having to pass the coding standards.

I guess I will just have to keep my more Java-like UML friendly contributed modules in the sandbox until maybe 'when 9.x is opened'

Interesting reading (a.k.a. spot on): Drupal is still a gated community (Mikkel Høgh)

[EDIT: quoting this article:

One of the things the Drupal community prides itself on, is how open the community is. And that is generally true, but there's one exception.

And that is the Kafkaesque horror-show we subject any newcomers that would like to publish their code on Drupal.org to. It goes by the name of “Project Applications“.

once you pass the initial review, you're given the keys to the kingdom. After that, you can create as many new project, and publish as much terrible code on Drupal.org as you want to.

Sincere thanks to Mikkel forever for having the guts to say it it how it is.
]

webel’s picture

webel CreditAttribution: webel as a volunteer commented
FileSize
Drupal setter lower_case arg standard.png78.01 KB

@crell wrote:

While there are good cases to be made for changing the coding standards, you're not making them.

Oh yes I am, you are just choosing not to notice them. In fact I have made very compelling technical arguments about why this coding standard should be changed, whereas you have not offered any compelling arguments about why the current standard has any benefit at all for OO coding. And just arguing that Java need not necessarily act as a template for the PHP coding standards for Drupal does nothing to support why this standard - which is clearly a legacy from pre-OO Drupal and not appropriate for use in a Class - should remain.

@crell wrote:

UML, AFAIK, has nothing to do with this. UML doesn't care about letter casing.

Model-driven development (whether for forward or reverse engineering) favours consistent code generation and consistent manual coding patterns:

That is a technical argument, in case you missed it this time.

webel’s picture

webel CreditAttribution: webel as a volunteer commented
Priority: Normal » Critical

I am going, just once here now, to bump this to critical in view of this statement from @crell:

It's also very unlikely that a standard this basic would change mid-cycle, so the earliest this could change, for better or worse, would be when 9.x is opened for development (which is still quite a ways away). I'd encourage you to get used to the current standard, because even if you did get everyone on board to change it, it wouldn't happen for some years yet.

If there is anything you can do to fix this (and it is basically broken, it needs fixing) before 9.x then please do it. Prioritise. Before this crazy coding pattern gets forced on anybody else (or encouraged in any way).

webel’s picture

webel CreditAttribution: webel as a volunteer commented

@crell wrote:

> even if you did get everyone on board to change it, it wouldn't happen for some years yet.

To change one sentence in the coding standards ? Or to change one regexp ?

Or maybe it could take just a few seconds (or at most minutes) and a little less stubbornness on the part of some TWG members on the Drupal Island.

Crell’s picture

Crell CreditAttribution: Crell as a volunteer commented

webel: Please, chill. You're undermining your own efforts here.

1) If you've been writing Drupal code for 8 years now, then it's not "your coding standards". It's "our coding standards", as in, you're part of the same community. Welcome. :-)

2) You may have technical arguments to make, but you're doing a piss poor job of making them. Here's how you come off: "My project application was rejected because you morons like underscores. Screw you and your project application process and 15 years of coding conventions! Change your entire frickin' code base to what I prefer right now or I'll take my ball and go home!"

Whether you intend it or not, you're coming off very childish. That's not going to encourage anyone to agree with you. If anything it's going to encourage people to reject your proposal out of spite, because no one wants to agree with a bully. That is, go ahead and take your ball home.

If you want to make a case for lowerCamel everything, the case to be made is learnability, consistency with trends in the broader PHP community (which is notoriously inconsistent on coding standards), ease of developing automated tooling, etc. Those sorts of arguments can work. I know; They're the sorts of arguments *I* used to push us toward broader OOP adoption in the first place. :-)

Even if you could make that case, though, the simple fact is that right now getting Drupal 8 released is absolute top priority, and anything that interferes with that goal will be rejected. Switching the coding standard right now would mean updating a massive codebase of hundreds of thousands of lines and breaking every patch currently in the issue queue. Even if we were to decide right this second, with no further discussion (hint: Drupal doesn't work that way and never has) to switch the coding standard, you're still going to add absolute bare minimum 2 weeks to the release cycle while the dust settles. We've held off on full-scale adoption of short-array syntax for the same reason. (#2135291: [Policy, no patch] PHP 5.4 short array syntax coding standards for Drupal 8) Regardless of whether changing the coding standards is a good idea or not, if you asked most core developers if camel case variables is worth delaying Drupal 8's release a minimum of 2 weeks (again, I'm being optimistic), they wouldn't even dignify the question with a response and get back to getting Drupal 8 released. After 3 and a half years, we all want it shipped. There are far, far more important and impactful changes that have been punted already in support of that goal.

It's possible that it could change during the D8 cycle, to allow both, though I suspect it's unlikely. But I'm certain that it won't happen before 8.0.0, even if everyone agreed with you that we should do it.

Side note: I am not a member of the TWG. I happened across this thread for other reasons and tried to be helpful. Your flippancy is not helping your case. Before responding again, please take a deep breath and read this: https://www.drupal.org/dcoc

webel’s picture

webel CreditAttribution: webel as a volunteer commented

@crell
> You may have technical arguments to make, but you're doing a piss poor job of making them. ..

So you say. Well I think you are making a piss poor effort of defending them (the current Drupal coding standards like this). Truly piss poor.

And it's not just for me. It's for every sane developer who has any decent experience with OO who may not wish to suffer your coding standards like this one for any more than the one day it would take to change it.

webel’s picture

webel CreditAttribution: webel as a volunteer commented

@crell:

> Switching the coding standard right now would mean updating a massive codebase of hundreds of thousands of lines and breaking every patch currently in the issue queue.

Utter nonsense. I don't particularly care whether others wish to write strange looking code with underscore parameters for argument to setters when at the same time they are told to use $camelCase private variables (if they so wish to do it, although I would not want to put @author on such code).

I just don't want to be told:

- By your coding standards pages.

- By Coder.

- By the Project Applications process with a robot script that does not know one is trying to demonstrate a pure object-oriented bridge for Drupal7, and spite all the time on very clean consistent code that is more consistent than your coding standard.

It is the Drupal standards effort that is applying the EITHER OR.

The same goes for having Interface adorning every single .. ahem .. interface. You (collectively on the Drupal Island) can do it if you like, just stop telling other people who don't agree with you that they have to, people who, for example, are reverse engineering their PHP code to UML (which indicates each Interface very clearly with a special symbol) or for that matter any person with a decent IDE like NetBeans. which surprise surprise already knows whether something is an Interface (because in design by contract and design against and interface you don't need to shout it from the roof).

If you open your collective minds, you could have both. More than one rule. At the same time.

Even on the Drupal Island.

webel’s picture

webel CreditAttribution: webel as a volunteer commented

@crell

> if you asked most core developers if camel case variables is worth delaying Drupal 8's release a minimum of 2 weeks ..

Firstly I have been making the case for this change for a very long time, including emails direct to TWG members, so the 2 weeks argument does not apply.

Overall, of the dozens of recommendations I have made (without any flippancy) and having spent a very large amount of time on, the coding standards effort has chosen to reject nearly every single one, and has done absolutely nothing to make it easier for me to contribute to the Drupal community.

It's either "do it the Drupal7/8 way" (for the next umpteen years) or catch the highway (at least until D9).

Coding Standards should not thwart innovation, and that is what this coding standards effort is doing, plain and simple. It has been a massive, most unappreciated, waste of my time.

And don't give me that garbage about the problem being how I have made my arguments; look through the queues and you'll see I have made a very special effort to give good reasons. But they basically all get rejected with "this is the Drupal way".

So eventually, all that is left, is to point out that much of what the coding standards team is doing is a bad joke and, yes basically, mock it.

webel’s picture

webel CreditAttribution: webel as a volunteer commented

WARNING: before you view this please know that @crell thinks this argument is "piss poor"

And this one is also apparently "piss poor"

Now, if you got this far, actually scan through my arguments already presented on the Coder queue as referenced at the top;

#2303963: Allow camelCase for variable naming conventions

And then, see if you can find, anywhere, in anything that @crell has said, a single technical argument in favour of the current Drupal setter coding standard, other than that just because Java does it the sane way that nearly everyone else has done it for centuries is not enough, or that Drupal does it that way because it will take a very long time to change because this is Drupal.

Now who is piss poor. I mean really.

Here's somethingI would like to know. How the hell can something as silly as this standard get inside the standards anyway if the people responsible for it have the foggiest clue about OO. Or maybe it's just "piss poor".

Dr Darren Kelly, Webel IT Australia (Piss Poor UML expert with a love of Java, and proud of it)

webel’s picture

webel CreditAttribution: webel as a volunteer commented

> the earliest this could change, for better or worse, would be when 9.x is opened for development (which is still quite a ways away)

"piss poor"

Not my words. Webel

David_Rothstein’s picture

David_Rothstein CreditAttribution: David_Rothstein as a volunteer commented

You might want to try calming down a bit....

Perhaps I'm missing it, but I don't see where the current coding standards even say this isn't allowed. It actually seems pretty ambiguous. At https://www.drupal.org/node/608152#naming it says:

Methods and class properties should use lowerCamel naming

but doesn't really say anything one way or the other about method arguments specifically, does it?

Seems to me that it's worth clarifying one way or other. Maybe the standards should just say either is allowed. It means some inconsistencies between the standards for procedural and object-oriented code, but those are already pretty inconsistent anyway.

RdeBoer’s picture

RdeBoer
Location Melbourne
CreditAttribution: RdeBoer as a volunteer commented

This discussion indeed seems much more heated than it needs to be.

If @David_Rothstein is correct, and the coding standard does indeed not explicitly impose camelCase for method arguments, then what @Webel is asking (in an overly uhm... "passionate" fashion) is in fact not to change the standard, but to bring the CodeR tool in line with it.

Either way... could an (interim) way forward for all of us be for the CodeR tool to not insist either way regarding method arguments, i.e. to no longer report "... do not use mixed case (camelCase), use lower case and _ ...".

With that rule commented out of CodeR, existing Drupal code will continue to pass, while at the same time (new) code following the OO style more common outside Drupal will not fail.

Having at least the option to use camelCase for arguments would make it easier for automated tools to parse Drupal code and do useful things with it.
I for one would love to see UML diagrams automatically generated from Drupal code. A coding standard that is sympathetic to both Drupal developer and their tools, will doubly add to the developer experience.

Crell’s picture

Crell CreditAttribution: Crell as a volunteer commented

Methods have always been interpreted in the same way as functions: A variable that doesn't have a -> before it uses $snake_case (as was common for most projects in the PHP 4 era), variables with a -> before them use lowerCamel. That's how we've been enforcing standards in core for the past 3 years. (Methods vs functions follow the same rule and distinction.)

Again: I'm not arguing against making a change here. I'm pointing out that making a change right now is highly unlikely.

webel’s picture

webel CreditAttribution: webel as a volunteer commented

To all who have replied. First some responses to selected points, and then below it some context about why I am so incredibly upset about this and about the general lack of response to my (not initially angry, upset, or mocking) coding standards issue reports, core issue reports, and my stalled project application process. Do read it, you might be surprised, and you might not be so quick to judge my at times (by now, not at first) clearly angry tone.

So, to the setter. Where setters and getters are the core of what it means to have one object INJECTED into another (and hence the arg of which should usually have the same name as the private variable it is setting).

@crell Before making it very clear that while you are criticising people's indeed technical arguments and how they make them (after years of being ignored), offensively comparing them to urine is not welcome:

> Methods have always been interpreted in the same way as functions

That's right. Which is as much to agree with what I have been pointing out, namely that it makes the Drupal community's efforts towards OO look pretty bad. Because here's a giant news flash: A method is not just a function, and if the people involved with this had any clue they would have made a provision for that as the very first step in the statement of the OO part of the coding standards. And they also would have noticed that Coder, sitting downstream, had adopted it.

> That's how we've been enforcing standards in core for the past 3 years. (

That's right. They have been doing something truly very silly for at least the past 3 years, and for just as long, I have been asking them not to, only to be ignored, until now I am told it is basically too late, and I will have to wait until Drupal 9.x (which let's face it, made me pretty angry to hear having tried to tell everyone for so long to prevent this getting into D8).

@RdeBoer

.. the coding standard does indeed not explicitly impose camelCase for method arguments,

But it is assumed to inherit the standard for functions. If you look at the original Coder report, this is discussed already: #2303963: Allow camelCase for variable naming conventions

Rik wrote:

. could an (interim) way forward for all of us be for the CodeR tool to not insist either way regarding method arguments, i.e. to no longer report "... do not use mixed case (camelCase), use lower case and _ ...".

My constructive meta-suggestion here, which has also received no traction, is to have different levels of compliance and Coder Compliance Profiles (which could be submitted alongside a project). Those who insist on doing it the Drupal way could use the standard compliance profile. Those who wish to use my UML-friendlier PHP recipe for Drupal (which is very consistent) could use a different coding standard profile (that maybe I manage). See #2306733: Advanced feature idea: Coder strict mode (applies all rules) and user selectable rule switches, together with Coder configuration file for submission with a module.

In any case, Rik has identified that the coding standards need not be so brutally EITHER OR.

@David_Rothstein

> I don't see where the current coding standards even say this isn't allowed.

It is assumed. See remarks above and remarks from @klausi under #2303963: Allow camelCase for variable naming conventions..

> You might want to try calming down a bit....

Sorry, I just have this funny thing where I don't appreciate having my compelling arguments compared to urine by others on this site. If you have any say on the matter, you might like to point out to @crell that he might like to not use such language in future on Drupal.org.

Please do also read Maybe Surprising Context below. BTW I did try calm, yes I tried it for some years, if you look at nearly every single issue report I made it was calm, but nothing happened. And it started to cost me a lot, and I mean a lot. What's about 6 months work unpaid over years worth to you ? And for no ultimate result ? To simply get stranded on the Project Applications queue ?

I assume you already have full Project rights ? If not, you might try not having them and then try to make a major contribution (completely unpaid, yes we are all unpaid aren't we, but do read below) to Drupal that requires innovation and where that innovation requires in parts a particular UML-friendlier PHP coding pattern that was not foreseen by most other Drupalers (and also requires a completely harmless tweak to D7 core to suppert OO form controllers that keeps getting ignored along with this similar one even though I supplied a patch for it). If you have not already, do please read this article by Mikkel Høgh Drupal is still a gated community which describes:

... the Kafkaesque horror-show we subject any newcomers that would like to publish their code on Drupal.org to. It goes by the name of “Project Applications“.

Some Maybe Surprising Context

Finally, having responded to some constructive points, if you are amused, surprised, or dismayed at my own level of annoyance with this matter, I suggest you look at in the context of the following. If you take the time to look at the multiple dozens of issue reports I have made under both the Coder issue queues and the Coding Standards queues over the last couple of years (and I track every one separately at my end to track whether there is any change or result) you'll find that:

1. In every case I have initially made calm issue reports making clear technical case (such as the one related to this #2303963: Allow camelCase for variable naming conventions), only to result in ...

2. Having every single recommendation basically either completely ignored or rejected without any consideration of my needs or any reward for my effort, other than to have a couple of inconsistencies I found acknowledged.

And then, after having my project application that I worked on for 4 months (unpaid, yep, we all do so much unpaid) held up for a year (also BTW because your core assumes that form callbacks are not-object-oriented and your core people keep ignoring my harmless suggestion for supporting a tiny change in D7 core to support methods and not just functions as callback in forms.inc) , I flipped, didn't I.

Now read this carefully. Yes, we all spend lots of time on projects free, but we don't all do it while going blind. That was B L I N D blind. As in not being able to see, and therefore not being able to contribute as easily to, for example, the Drupal community. Maybe never again.

Luckily, my eyes were saved by a very tricky surgeon. Now sadly, a couple of weeks ago, I suffered a retinal detachment again (that is the back of the eye falling off) in my right eye (it had already happened in my left eye, and in both eyes I had early onset of cataracts so I could at one stage not see anything), and luckily, a surgeon was able to save it just in time. I am recovering.

Now during such times it gives one enormous focus about what one wants to do, what matters, and who the time wasters are. Which brings me to Drupal, which I have used for about 8 years, but the API of which, the coding style of which, and module development system of which I have never liked (compared to other technologies I use).

During my time unable to see properly (and at one stage not at all), I reflected on what I want to spend my perhaps limited time on, and being a true model-driven engineering fan, and having already had a vision of how both UML and SysML can be used to benefit Drupal, I decided to commence my Object Oriented Examples (OOE) project to demonstrate how UML can be used with PHP to develop a truly OO bridge for D7 (and hence also how D8 might be better developed) and my Flag Plus project to show how UML can be used to progressively refactor a typical non-OO Drupal7 project using just static helper methods in Helper classes. They are educational demo projects. That is what they are for.

But the Drupal processes, the Drupal TWG, and the Drupal Coding Standards teams, turned out to be the most difficult, the most incredibly stubborn, defensive, inflexible, mind-numbingly unresponsive and unhelpful technical effort I have ever dealt with in over 3 decades of working on software engineering

Precious, precious, precious. "This is the Drupal way".

Who is the blind one ? For me, for the amount of "technical love" it has brought me, for the amount you have listened collectively, as a community, at all, to anything I have had to say, by direct email, or via issues and forums - especially regarding OO, and the potential use of graphical UML with PHP - it has been like throwing a massive amount of unpaid time into a great big black hole.

Precious, precious, precious. "This is the Drupal way".

And don't anybody please give me again that nonsense about it being how I have said it; that's just become a lame excuse for people not to act. Kelly (Webel) is angry, we won't react. It misses the point that I am in fact trying to make sure that every other Drupal user who has past experience with OO and wishes to see certain basic, common sense conventions respected is not also inconvenienced (or left wondering what on earth the Drupal coding standards team had in mind).

I spent a lot of time yesterday reviewing my own issues. There are very technically cogent. But now, now I am truly fed up. And angry. I mean really, really angry. The main problem is not me; the main problem is that you are collectively incredibly precious about your Drupal way, incredibly defensive, incapable of benefiting from constructive criticism, and the effort you put into defending "the Drupal way" of doing things could better be spent changing things.

One not XOR regexp. One line in the OO coding standards docs page. Done.

Again: I am trying to make one of the biggest contributions ever in the history of Drupal, but your processes and your collective pig-headedness are making it incredibly hard to do before I maybe go blind (which maybe I won't, but believe me when I say I might still).

And again: the Drupal community is officially in my basket of "massive time wasters", at least until you can demonstrate that you are in fact in the position to actually receive input about better ways of doing things from people who truly do know how, but who do not subscribe to Drupal Dogma on the Drupal Island.

And once again: the fact that you let this setter matter actually get into Coder, so that many of you have been seeing the Coder warning and ignoring it (or worse, you have been coding the setter method as currently recommended for a non-OO function without slapping yourselves each time) makes the Drupal teams' efforts at OO look, quite simply, very bad. You can't be surprised to be ultimately mocked for it.

Now if you got this far, have a look at the effort I have put in to catch problems in your coding standards and in Coder, and then notice the amount of actual help, the number of concessions, or any genuine "softeng love" at all I got for these dozens of reports done on my own time over years: https://www.drupal.org/user/392755/track

Benefit ? Reward ?

0: Zero: Zilch

Like the singularity of a black hole

Darren Kelly (Webel)

[EDIT: edited to remove some typos, and in some cases some inadvertent word replacements. Forgive, I am having trouble seeing.]

pfrenssen’s picture

pfrenssen
Location Sofia
CreditAttribution: pfrenssen for European Commission and European Union Institutions, Agencies and Bodies commented
Priority: Critical » Normal

-1 from me.

It is a minor cosmetic change which would require thousands of man hours to fix in core alone. It would probably take several years to fix in contrib. We have much bigger fish to fry. Also whether or not this looks right is highly subjective. To my eyes the suggested change looks worse than using snake case for arguments, but then again I'm biased after looking at Drupal code for years. Subjective indeed.

The UML argument doesn't really stand. We have consistent naming, $author_name can be directly associated with $this->authorName. If an UML generating tool does not support it, then adding support for it is just one pull request away.

Xano’s picture

Xano
he/they
Primary language English
Location Southampton
CreditAttribution: Xano at Druid commented
Status: Active » Closed (duplicate)

This seems like a duplicate of #2411911: [policy, no patch] snake_case in coding standards makes consistency interoperability hard. Let's continue there, and keep things civilized. Ad hominems are not appreciated, and discussions about other problems with Drupal or one's life (however important they may be in their own context) are not relevant and only clog up the issue.

dawehner’s picture

dawehner
Primary language German
CreditAttribution: dawehner as a volunteer commented

I think we should just give freedom for people. If they want to go camelCase, just allow them to do that and be done.
Those things should not held back a project review, IMHO.

Personally I think we made a mistake by not adapting PSR-2, just because we haven't been used to that style.

donquixote’s picture

donquixote CreditAttribution: donquixote as a volunteer commented

I think we should just give freedom for people. If they want to go camelCase, just allow them to do that and be done.
Those things should not held back a project review, IMHO.

+1 from me.
I am already using this (very inconsistently) in some of my contrib and custom code. And luckily I already went through the review process long ago. I can totally understand how this would upset someone if a project is being blocked because of this, even if this one might be extraordinarily passionate.

@webel:
Yes it totally is a legacy thing. But legacy reasons can be valid reasons.
(I also think to have seen a recurring pattern where we postpone stuff forever, only to then say it is too late.)

And it is not just about method arguments. If we did camelCase for method arguments, the next thing would be local variables. Do we want them to be snake_case, whereas arguments are camelCase? Then if we change local variables, we probably want to change them everywhere. Otherwise it would be hard to copy code between procedural and OOP parts.
Which is where we get to the leftover procedural code, and the question whether function arguments should use camelCase. And then, whether function names should be camelCase.

webel’s picture

webel CreditAttribution: webel as a volunteer commented

@donquixote

Yes it totally is a legacy thing. But legacy reasons can be valid reasons.

Can be, but aren't here.

You makes the observation that this could have implications for local variables within class methods and copied procedural code:

If we did camelCase for method arguments, the next thing would be local variables. Do we want them to be snake_case, whereas arguments are camelCase?

If you are dealing with manipulating a local variable that will be assigned to private variable, where the $camelCase convention for private variables is already in the standard, it makes sense to permit $camelCase here too, for the same reason that an injected argument variable should be permitted to be the same.

Then if we change local variables, we probably want to change them everywhere. Otherwise it would be hard to copy code between procedural and OOP parts.

There is always going to be an "impedance mismatch" no matter what you do, as long as the conventions for procedural and OO are different; it just to me makes a lot more sense to make that mismatch favour the OO side (be consistent for it) especially if you have the one big chance during the migration now, and especially when a Setter is for injecting something to match up exactly with something else (the private var).

I have a closely related problem in my special OOE Bridge,classes which translates between the .module hook world and the fully OO side (for D7); I use lower_case() for methods just in the bridge class wherever it is a delegate from the .module file's hook_lower_case(), to make it very clear that it is a hook delegate, and I mark it with a stereotype «hook» in the UML model. In this case, Coder reports that I am using an inconsistent method name (because using lower_case()), but that one bridge class plays a very special role in translating between procedural and OO, it makes sense there to have mixed conventions.

webel’s picture

webel CreditAttribution: webel as a volunteer commented

@pfrenssen

> It is a minor cosmetic change which would require thousands of man hours to fix in core alone.

It does not have to be an EITHER the current Drupal way XOR the way just about every OO language (like Java) in the world recommends.

It does not have to be exclusive.

If you want to have it this way still in core (I would not, but if you all want to keep it so badly) just don't force the current rule on other people. Permit the consistent form I recommend.

Besides: if someone had bothered to see how most other OO languages do it first, then you would not have 1000s of man hours to undo (fix).

kattekrab’s picture

kattekrab CreditAttribution: kattekrab as a volunteer and at Creative Contingencies commented

This is the 2nd issue that's been brought to the attention of the Community Working Group in recent days with clear breaches of our code of conduct.

A reminder to please

  • Be considerate.
  • Be respectful.
  • Be collaborative.
  • When we disagree, we consult others.

- https://www.drupal.org/dcoc

donquixote’s picture

donquixote CreditAttribution: donquixote as a volunteer commented
Related issues: +#2411911: [policy, no patch] snake_case in coding standards makes consistency interoperability hard

I have a closely related problem in my special OOE Bridge,classes which translates between the .module hook world and the fully OO side (for D7); I use lower_case() for methods just in the bridge class wherever it is a delegate from the .module file's hook_lower_case(), to make it very clear that it is a hook delegate, and I mark it with a stereotype «hook» in the UML model. In this case, Coder reports that I am using an inconsistent method name (because using lower_case()), but that one bridge class plays a very special role in translating between procedural and OO, it makes sense there to have mixed conventions.

I see how this can make sense n some cases.
For the same reason we have namespaces like Drupal\mod_ule\Foo, instead of Drupal\ModUle\Foo. The deviation from the rule communicates something, it is intentional.

If you want to have it this way still in core (I would not, but if you all want to keep it so badly) just don't force the current rule on other people. Permit the consistent form I recommend.

Which is what is already being suggested in the other issue, #2411911: [policy, no patch] snake_case in coding standards makes consistency interoperability hard (for contrib, not for core). So you are no longer alone. Doesn't that feel good?

My constructive meta-suggestion here, which has also received no traction, is to have different levels of compliance and Coder Compliance Profiles (which could be submitted alongside a project).

It is a nice idea. But I can fully understand if this is not within the intended scope of the coder module atm - not up to me to decide.

webel’s picture

webel CreditAttribution: webel as a volunteer commented

@donquixote Without responding to any of your other astute observations because there is nothing to add:

> So you are no longer alone. Doesn't that feel good?

Alone ? No, I did not ever feel alone, no not at all, not even a tiny bit.. Because I am "with" the massive, decades old, overwhelmingly consistent OO community, and most model-driven software engineering advocates, being much much larger than the Drupal user community, even with many PHP OO users abord, astronomically beyond Drupal Island's non-OO procedural "flatland", who choose to use the consistent setter pattern.

Crell’s picture

Crell CreditAttribution: Crell as a volunteer commented

webel: "Piss poor" was perhaps a poor choice of words earlier (possibly too much of an Americanism), and I apologize for that, although I believe the criticisms of your tone and style as being counter-productive to your goal are still valid. I wish you would realize that every time you insult the general consensus or intelligence of Drupal developers ("flatland" mentality, etc.) you make it harder for people to agree with you or support the change you're asking for.

David_Rothstein’s picture

David_Rothstein CreditAttribution: David_Rothstein as a volunteer commented

@webel, regarding the Drupal 7 core patches you mentioned, sometimes core patches stall because not too many other people happen to be interested enough in the issue to review it... It can be helpful to cross-link them with other related issues sometimes, as a way to find reviewers. For example, #2342667: Cron and batch processing of queues are not accepting callables looks like a closely-related issue that was recently marked RTBC and will likely be included in the next Drupal 7 core release. You could post there linking to your issue and maybe see if anyone following that issue is interested in reviewing yours.

Also, best wishes to you on your health.

David_Rothstein’s picture

David_Rothstein CreditAttribution: David_Rothstein as a volunteer commented
Status: Closed (duplicate) » Active

I actually think this isn't necessarily a duplicate, since #2411911: [policy, no patch] snake_case in coding standards makes consistency interoperability hard is a much broader issue that proposes changing the standard everywhere (or at least everywhere in object-oriented code); this is just about setter methods.

Maybe it has to be everywhere since people don't always like having standards that are inconsistent. But I think a possible proposal for this issue would be something like: "Method arguments should use snake case. However, if the method's only purpose is to interact with class variables (for example, a setter method) then it is acceptable to use camel case instead."

webel’s picture

webel CreditAttribution: webel as a volunteer commented

@David_Rothstein

> I actually think this isn't necessarily a duplicate .. #2411911: [policy, no patch] snake_case in coding standards makes consistency interoperability hard

I agree, and thanks for re-activating this as a distinct issue.

"Method arguments should use snake case. However, if the method's only purpose is to interact with class variables (for example, a setter method) then it is acceptable to use camel case instead."

Without reigniting the debate, I am for completely consistent use of $camelCase throughout the contents of or in arguments to any class method, even for local variables. I am not for any exclusive/excluding/enforced "importing" of any part of the older Drupal standards regarding use of variables inside or as arguments to procedural functions.

donquixote’s picture

donquixote CreditAttribution: donquixote as a volunteer commented

Also, given where we are in the dev cycle I can say with certainty that the coding standards will NOT change before 8.0.0 is released, as it would be far too disruptive to do so.

For the record: A change like this in core would not technically be API-breaking.
And it won't break contrib if it is considered optional for contrib.

It will cause inconvenience in contrib classes that inherit from core classes or implement core interfaces, and have to rename their variables - equivalent to the inconvenience we currently have when implementing 3rd party library interfaces, as bojanz is pointing out in #2411911: [policy, no patch] snake_case in coding standards makes consistency interoperability hard. But it won't break it.

tizzo’s picture

tizzo CreditAttribution: tizzo commented
Project: Drupal Technical Working Group » Coding Standards

Moving this issue to the Coding Standards queue per the new workflow defined in #2428153: Create and document a process for updating coding standards.

klausi’s picture

klausi
he/him||they/them
Primary language German
Location 🇦🇹 Vienna
CreditAttribution: klausi commented
Status: Active » Closed (duplicate)

Duplicate of #2648050: [policy, no patch] Stop disallowing camelCase for local variables / parameters.