Final underscore in class names

[Marco Perone]

As per PSR-1 specifications, class names must be in StudlyCaps.

However, if I want to define a class named Echo (or any other Php keyword), I am not able to do that beacuse if I do so I obtain a parse error.

It seems that the standard solution to this issue is to add an _ at the end of the class, as in Echo_.

For example, look in https://github.com/nikic/PHP-Parser/tree/3.x/lib/PhpParser/Node/Stmt.

Should this be counted as a violation of PSR-1?

Could it be the case to state this explicitely in PSR-12, allowing the presence of a final underscore in a class name, maybe only when the class name in a reserved keyword?

More broadly, could it be the case to provice a precise definition of what StudlyCaps mean? (If it's not present elsewhere and I'm missing it...)

[Paul Dragoonis]

Hi Marco,

Comments inline.

On Thu, Mar 9, 2017 at 10:40 PM, Marco Perone <pasa...@gmail.com> wrote:

As per PSR-1 specifications, class names must be in StudlyCaps.

However, if I want to define a class named Echo (or any other Php keyword), I am not able to do that beacuse if I do so I obtain a parse error.

It seems that the standard solution to this issue is to add an _ at the end of the class, as in Echo_.

No, this is not the standard solution.

 

For example, look in https://github.com/nikic/PHP-Parser/tree/3.x/lib/PhpParser/Node/Stmt.

This would not pass PSR-1 codesniffer tests. 

Should this be counted as a violation of PSR-1?

Could it be the case to state this explicitely in PSR-12, allowing the presence of a final underscore in a class name, maybe only when the class name in a reserved keyword?

Where possible you should avoid naming your classes after language constructs and tokens.

 

More broadly, could it be the case to provice a precise definition of what StudlyCaps mean? (If it's not present elsewhere and I'm missing it...)

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscribe@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/e07dbe3c-2488-4630-8850-bdb04ccae52b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Marco Perone]

Hi Paul, thanks for your answer,

I know that the final underscore is not passing the PSR-1 codesniffer test. That's where I started from (https://github.com/squizlabs/PHP_CodeSniffer/issues/1382). I was more wondering if that is the correct approach.

I agree it should be generally avoided to name classes after language constructs, but there are cases (see the PHP parser library I linked) where that seems exactly the most reasonable thing to do, and I am asking how these cases should be handled.

--
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/0yEk60y2RVE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+unsubscribe@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAKxcST_xhaRhpnn8jV8jVDRQXMO4c98%2BN3HsV3d3mJ-Zyri%2BhQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Marco Perone

@marcoshuttle

https://github.com/marcosh

http://marcosh.github.io/

[Paul Dragoonis]

Hi Marco,

On Fri, Mar 10, 2017 at 9:25 AM, Marco Perone <pasa...@gmail.com> wrote:

Hi Paul, thanks for your answer,

I know that the final underscore is not passing the PSR-1 codesniffer test. That's where I started from (https://github.com/squizlabs/PHP_CodeSniffer/issues/1382). I was more wondering if that is the correct approach.

The correct approach is to stick to StudlyCaps for class name. If it deviates from that then it's considered "not compliant".

 

I agree it should be generally avoided to name classes after language constructs, but there are cases (see the PHP parser library I linked) where that seems exactly the most reasonable thing to do, and I am asking how these cases should be handled.

Indeed projects like this aimed to emulate the tokens of the language will find themselves falling outside of PSR-1. There's nothing wrong with that really.

A personal suggestion, so you're sticking to StudlyCaps, is you could do something like TokenEcho TokenEmpty for class names, if PSR-1 is important to you.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAARDrK-W5SarhO4p3YaUGOdL9ScO%2BKwyNDm0gukZYGymkduezw%40mail.gmail.com.

[Jason Judge]

On Thursday, 9 March 2017 22:40:08 UTC, Marco Perone wrote:

...

More broadly, could it be the case to provice a precise definition of what StudlyCaps mean? (If it's not present elsewhere and I'm missing it...)

 I'm wondering whether this is a term we should be even using? It seems that aNyThiNG can be called studycaps if it mixes upper and lower case letters in a word, it is such a broad definition. Wikipedia describes camel case as a form of studycaps where only the first letter of each joined words is capitalised. And then there are two forms of that: upper camel case and lower camel case, depending on whether the first letter of the first work is capitalised.

Of course we all know the intention in this PR was to use upper camel case for ClassNames, but a good and unambiguous definition will always beat just knowing. It can also beat the various conventions that have grown in different programming environments.