Clarify the coding standard about naming

[VincentLanglet]

TLDR: I think the twig coding standard about variable casing should be either removed, either precised.

In the twig coding standard https://github.com/twigphp/Twig/blob/3.x/doc/coding_standards.rst#coding-standards, there is the following rule

Use lower cased and underscored variable names.

{% set foo = 'foo' %}
{% set foo_bar = 'foo' %}

But there is nothing about

• Variable passed by the controller to the view
• Method/filter names
• Getter usage

Since twig started to take a decision about the right casing in twig files, IMHO it should be more precise about all the possible situation ; or in the contrary, it shouldn't start to take a decision.

Variable passed by the controller to the view

Currently in controller I only saw camelCase variable passed to the view, like https://github.com/symfony/demo/blob/main/src/Controller/BlogController.php#L62 Which means we would end up with both camelCased and snakeCased variable in the same template.

I'm not sure it's the best. If I used a reusable template which need some value FooBar, should I then call is foo_bar or instead fooBar ? Let's say foo_bar is recommended then if I use this template, I could have to add with {foo_bar: fooBar} if I use it with a variable passed by the controller...

So should snake_case` be recommended for the value passed from the controller to the view ?

Method/filter names

Looking at all the method/filter provided by twig, like html_to_markdown it seems like snakeCase is use. I think it could be added to the coding standard

Getter usage

Let's say I have a class Foo with a method getMyBar. Should I write foo.myBar or foo.mybar or foo.my_bar ? (I don't even know if the last one is supported)

I currently see a lot camelCase for this situation. Let's say the class is SuperFoo now. I could end with code like this

{% set super_foo = ... %}
{% set my_bar = super_foo.myBar %}

So it leads to using both camelCase and snakeCase in the same expression. Not sure is great.

[VincentLanglet]

Friendly ping @fabpot, would it be possible to have more information about the coding standard of twig about naming ? I'll be happy to provide a PR to improve the doc then.

[SpacePossum]

Let's say I have a class Foo with a method getMyBar.
Should I write foo.myBar or foo.mybar or foo.my_bar ? (I don't even know if the last one is supported)

For performance you are best of using foo.getMyBar.

On the topic of CS, I think the recommendations in the doc are correct and as precise as can be. As these are framework/platform and context agnostic. What should happen if a Controller (assuming a SF controller) passes a variable name in camel case to Twig is something I think is better sorted in the CS docs of the project (like SF CS style). Just IMHO :)

[filecage]

I'm adding a note here to an issue I've created one year ago which addresses a similar thing: the internal "normalisation" of argument casing in #3475. This is beyond clarification in standards, but also adresses possible confusion and is a push towards "remove this standard".