So, we got off the island, and we're using libraries.

However, the entire outside world is using PSR-2, which means camelCase variables. Which means interfaces with method signatures that use camelCase variables.
D8 still uses snake_case for things that aren't class properties, for some odd inconsistent reason.

So, if a class implements one external interface, and one core interface, you get some methods with snake_case arguments, and some with camelCase arguments.
Drupal core has this problem when integrating with Symfony, but the number of classes with the problem is small and less visible.

Commerce however, has decided to move core logic and interfaces to external libraries, and our every entity implements a foreign interface.
So, right now Commerce method arguments are 90% camelCase, and 10% snake_case (constructors and form() methods, basically).
Based on this, and following positive community feedback, I'm about to create a "Commerce uses camelCase everywhere internally" rule, and break Drupal coding standards for the entire 2.x cycle.

larowlan wanted me to document my experience, so here it is. I know changing to camelCase in the D8 cycle is extremely unlikely, our choices have just left us in a painful position.

Comments

bojanz’s picture

bojanz commented
Issue tags: +DX (Developer Experience)
larowlan’s picture

larowlan
Location 🇦🇺🏝.au GMT+10
commented

Realise this is off the table for 8.x, into 9.x territory.
But we have code-generators etc and if we decided to move in this direction, we could do so in one jump with things like pharborist. Maybe when we decide to open the 9.x branch for development?

bojanz’s picture

bojanz commented
Issue summary: View changes
tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented

Is Commerce also going to use 4 spaces for indenting?
Or opening { on new lines?
Or any of the other asinine rules proscribed by PSR-2?

I don't see the point. PSR-1 is enough.

bojanz’s picture

bojanz commented

@tim.plunkett
No, just the minimum required to stay internally consistent. It's all about the variables, as imposed by the interfaces.

Hence the title of the issue being about snake_case, not full PSR-2.

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented

Good point, the only part of PSR-2 that would affect runtime PHP code is the variable names.
Fair enough.

xano’s picture

xano
he/they
Primary language English
Location Southampton
commented

Interfaces impose a number of parameters, and their types and default values. Parameter names can be changed in implementations, however. Example.

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented

Oh duh, we do that already in a couple places. Whoops, thanks.

Won't fix?

bojanz’s picture

bojanz commented

Sure, you can change the argument name. But that makes every inherited docblock now wrong, which would be a bit of a WTF to people reading the docs.
(Perhaps redeclare the docs?)
The feedback on #drupal-contribute was that breaking Drupal's coding standard was the less weird option here.

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
commented
Title: snake_case in coding standards makes consistency interoperability hard » [policy, no patch] snake_case in coding standards makes consistency interoperability hard

If we are designing code to be interoperable then going with camel case makes sense. And yep we probably have to move to camel case properties in d9.

dawehner’s picture

dawehner
Primary language German
commented

It is a hard topic.

If we are honest, we should have went with the PSR-2 code style. You know, code style is something your brain accepts and get used to it.
The only problem is, if you have to switch between different styles.

You though could also ask various vendors (STORM, phpdoc) to just care about the order of parameters, not the names.

jhodgdon’s picture

jhodgdon
she/her
Primary language English
commented
Project: Drupal core » Drupal Technical Working Group
Version: 8.0.x-dev »
Component: documentation » Documentation

This looks like a project-wide coding standards discussion, not a Core-specific coding standards discussion. So it should (sigh) be in the (semi-defunct at least) Technical Working Group issue queue.

David_Rothstein’s picture

David_Rothstein commented

Something that came up in #2474561: Coding standard: inconsistent requirement that arguments to setters methods should be $lower_case when private variable and setter methods are camelCase() (a closely related issue) is that currently there is no coding standard for this one way or another. There is sort of a de facto standard that method arguments use snake case (to match function arguments), but it's actually not written in the official coding standards at all, as far as I can tell. It would be good to clarify that either way.

tizzo’s picture

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.

gapple’s picture

gapple
he/they
Primary language English
commented
Status: Active » Closed (duplicate)

I think this can be marked as a duplicate of #2648050: [policy, no patch] Stop disallowing camelCase for local variables / parameters, which has been marked RTBC

pfrenssen’s picture

pfrenssen
Location Sofia
commented

Actually PSR-2 doesn't say anything about requiring camel case for variables or properties :)

It even gives examples that mix both camel case and snake case in a single variable name, which is kind of ridiculous:

$longArgs_noVars = function (
    $longArgument,
    $longerArgument,
    $muchLongerArgument
) {
   // body
};

PSR-2 builds on top of PSR-1 which specifically allows projects to choose their own style:

This guide intentionally avoids any recommendation regarding the use of $StudlyCaps, $camelCase, or $under_score property names.

Whatever naming convention is used SHOULD be applied consistently within a reasonable scope. That scope may be vendor-level, package-level, class-level, or method-level.