Make camelCase variable naming preferred over snake_case

+1 for moving this forward as @xjm describes in #15

Attempting a re-title, but this also needs an issue summary update.

@catch what about the public static function create() {...}? I think it falls in the same category but the proposed title doesn't cover it.

I think we have essentially done this issue in #2648050: [policy, no patch] Stop disallowing camelCase for local variables / parameters → the way that worked out - i.e. we're just allowing either style for local variables now. Is there anything else to do here?

@catch, I think this part from standards is the problem

Be consistent, do not mix camelCase and snake_case variables inside a method or function.

A constructor extending the parent (which have snake_case params) cannot add a new param with constructor property promotion because that is camelCase. So, it will mix snake_case with camelCase, violating the quoted text

@claudiu.cristea OK that makes sense, let's reword or remove that. Updated the issue title for now.

The issue summary needs to be completed.

I now updated the IS and added a suggested text (and my support):

Variables should be named using lowercase, and words should be separated either with uppercase characters (example: $lowerCamelCase) or with an underscore (example: $snake_case). Be consistent; do not mix camelCase and snake_case variable naming inside a file. The only exception is when adding property promotion to a constructor: properties should always use camelCase, even if the rest of the file uses snake_case for variables.

(The last sentence is the addition, everything else was left as-is.)

I think it would also be helpful to include guidelines and examples/suggestions regarding acronyms in class names. Sometimes you see stuff like SMTPManager, which is harder to read and looks bad, versus SmtpManager, which is preferable.

I think it would also be helpful to include guidelines and examples/suggestions regarding acronyms in class and variable names. Sometimes you see stuff like SMTPManager, which is harder to read and looks bad, versus SmtpManager, which is preferable. Same with variables like $mySmtpManager. The acronym should be treated and (title/lower)cased like a word.

This is already in the current standard, see item 3 of Naming → .

Okay. In that case, several contrib modules don't follow the standard and there's no coder rule to detect that, to my knowledge.

Variables should be named using lowercase, and words should be separated either with uppercase characters (example: $lowerCamelCase) or with an underscore (example: $snake_case). Be consistent; do not mix camelCase and snake_case variable naming inside a file.

The one exception is for property promotion in a constructor method. In a constructor, properties should always be camelCase.

I had difficulty reading the last sentence so I rewrote it. And more to a new paragraph for visibility of the exception. What do you think?

I think the amended text reads well.

Thanks, yes, good improvement. I’m just not 100% happy about the last sentence, “In a constructor, properties should always be camelCase.“ For one, it’s not just in a constructor that we proscribe camelCase for properties, but also I guess the usual exception (i.e., config entity properties) would still apply even when using property promotion.
Also, I feel that it might be confusing how this is even an exception without my last half-sentence?

I’m currently too tired to come up with a better phrasing (it’s pretty tricky to get across clearly and concisely), but we might also want to just link to the general naming conventions for properties → to make people aware of them and maybe help explain this exception for mixed variable naming styles.

Maybe something like this, as a completely different approach:

Variables should be named using lowercase, and words should be separated either with uppercase characters (example: $lowerCamelCase) or with an underscore (example: $snake_case). Be consistent; do not mix camelCase and snake_case variable naming inside a file.

Properties that are defined with property promotion in the constructor do not count as variables in this sense and should follow the general property naming conventions → instead.

I find the phrase, "in this sense", confusing but like the link. How about this;

Properties that are defined with property promotion should follow the property naming conventions in naming conventions → .

Updated the IS with the proposal from the last two comments and fixed the link.

The change proposed here allows snake_case to coexist in a file with promoted properties, which is good!
So I support this change, in general.

What I still don't like is that right now we don't have a clear preference in core whether to use snake_case or lowerCamel, and that decision is left to MR authors. I have seen MRs that keep the old snake_case but also some that move to lowerCamel on a by-file basis.
I think it is ok to be more flexible for contrib and custom code that wants to use Drupal conventions, but I think for core we should have some kind of guideline.

My personal preference is currently snake_case, partly because of arguments of readability made in the past, which at the time I was skeptical about but which I think do have merit. But I think this should be secondary here, my main point is I don't like it to be arbitrary. The point of conventions is to eliminate meaningless choices.

The conflict with promoted constructor parameters can be resolved in different ways:

• For promoted properties, the respective parameters shall also be lowerCamel (which they have to, naturally).
• For a constructor with at least one promoted property, all parameters shall be lowerCamel.
  This will allow to convert other parameters to promoted properties in the future, without breaking named argument calls.
• For any constructor, the parameters shall be lowerCamel.
  This will allow to convert that constructor to use property promotion in the future, without breaking named argument calls. Everything else remains snake_case.
• For any constructor and any static factory, the parameters shall be lowerCamel.
  This allows to copy parameter lists more easily between constructor and factory.
• Every parameter of any method in a class (that has a constructor or may get one in the future, which means any class) shall be lowerCamel.
  (I don't really like this one, it is just to extend consistency half way.)
• Every parameter and every local variable in a class file shall be lowerCamel.
  (This is what I see in some MRs)

Outside of property promotion, we could also say things like:

• Files copied from elsewhere, or files already existing in Drupal core, can preserve the naming style for parameters and local variables, as long as it is one of snake_case and lowerCamel.
• For newly added class files, the preference as expressed above applies.

All of this can be a follow-up.