PSR-1: StudlyCaps and camelCase definition

[Adam Backstrom]

Would PSR-1 benefit from a more detailed description of both
StudlyCaps and camelCase? Mostly, I would hope to remove
potential ambiguity around acronyms in class names. To use
some examples from Zend:

- Zend\Config, Zend\EventManager -- as expected
- Zend\Http, Zend\Rest -- acronyms get initial capital only
- Zend\OAuth -- weird edge case

[Dowling, Michael]

I think that would fall more into the PSR-2 style guide, right?

I've always favored strict camel casing as a rule (Http, Xml, etc). If
applied globally to a project, it makes it easier to know the name of a
class and easier to read classes with acronyms in them -- Foo\JSONLint vs
Foo\JsonLint. This convention also makes it easier to inflect between
snake_case and camelCase.

-Michael

>--
>You received this message because you are subscribed to the Google Groups
>"PHP Standards Working Group" group.
>To post to this group, send email to php-st...@googlegroups.com.
>To unsubscribe from this group, send email to
>php-standard...@googlegroups.com.
>For more options, visit this group at
>http://groups.google.com/group/php-standards?hl=en.
>

[Ryan Parman]

Since class and method names fall into compatibility, I think there's a fair argument in favor of this falling into PSR-1 territory -- especially since these two areas were called-out specifically in the PSR-1 proposal. Is there room in the process for updating approved PSRs with clarification language? This is what we do on the RSS Advisory Board (where we're up to RSS version 2.0.11).

My personal preference has always been the reverse (e.g., JSONEncoder, HTTPClient, XMLParser). As I've mentioned to Michael before, the opposite format makes my eye twitch uncontrollably. :)

> This convention also makes it easier to inflect between
> snake_case and camelCase.

Perhaps *slightly* easier. (I have a string inflector in another IDE tab that handles this case just fine.) I don't know that there's a winning rationale for either format; It may simply be a matter of preference. I think that by NOT specifying it, we can allow projects/teams to follow their preferred format... which is perfectly fine by me.

[justin]

On Tue, Jun 5, 2012 at 9:03 PM, Ryan Parman <ry...@ryanparman.com> wrote:
> Perhaps *slightly* easier. (I have a string inflector in another IDE tab that handles this case just fine.) I don't know that there's a winning rationale for either format; It may simply be a matter of preference. I think that by NOT specifying it, we can allow projects/teams to follow their preferred format... which is perfectly fine by me.

+1 (but it's an imaginary +1, since i'm not cool enough to vote on things)

-- justin

[Robin Winslow]

I've always wondered how to do camelCase and StudlyCaps in these cases. I like the idea of lower-casing all acronyms (Http, HttpManager) and I'm also interested in how OAuth or JQuery should be dealt with. I suppose the only solution is to do them just like that with two leading capitals. Thoughts?

I certainly would welcome these cases being specifically defined in the PSR standards.

[Paul M. Jones]

On Jun 6, 2012, at 5:31 AM, Robin Winslow wrote:

> I've always wondered how to do camelCase and StudlyCaps in these cases. I like the idea of lower-casing all acronyms (Http, HttpManager) and I'm also interested in how OAuth or JQuery should be dealt with. I suppose the only solution is to do them just like that with two leading capitals. Thoughts?

It occurs to me that it would be useful to be able to convert between StudlyCaps, camelCase, and snake_case forms (say, for taking SQL column names and turning them into method names). Some example bits:

// camelCase and StudlyCaps to snake_case
public function camelToSnake($str)
{
$str = preg_replace('/([a-z])([A-Z])/', '$1 $2', $str);
$str = str_replace(' ', '_', strtolower($str));
return $str;
}

// snake_case to camelCase
public function snakeToCamel($str)
{
$str = ucwords(str_replace('_', ' ', $str));
$str = str_replace(' ', '', $str);
return lcfirst($str);
}

// snake_case to StudlyCaps
public function snakeToStudly($str)
{
$str = ucwords(str_replace('_', ' ', $str));
$str = str_replace(' ', '', $str);
return ucfirst($str);
}

This particular implementation means that having (e.g.) OAuthHTTP won't necessarily get translated right; it would have to be OauthHttp to reliably convert back-and-forth to oauthHttp and oauth_http.

Thoughts?


-- pmj

[Andreas Möller]

> I've always wondered how to do camelCase and StudlyCaps in these cases. I like the idea of lower-casing all acronyms (Http, HttpManager) and I'm also interested in how OAuth or JQuery should be dealt with. I suppose the only solution is to do them just like that with two leading capitals. Thoughts?

I'm fine with how Zend suggests to handle acronyms in their naming
conventions for ZF1.

* ZendX\JQuery
* Zend\Pdf
* Zend_Controller_Request_Http

etc.


Andreas

[Bryan Geraghty]

This is a tricky area because there is the potential for problems in automation (as demonstrated by pmjones) but in reality, casting a namespace to a field name seems like a really terrible design choice.

My question is: Would we be improving interoperability by defining this rule or would be creating an unnecessary limitation?

Bryan

[Paul M. Jones]

On Jun 6, 2012, at 9:12 PM, Bryan Geraghty wrote:

> This is a tricky area because there is the potential for problems in automation (as demonstrated by pmjones) but in reality, casting a namespace to a field name seems like a really terrible design choice.

/me nods

In fairness, it applies to more than that: e.g., converting to and from SQL column names.

> My question is: Would we be improving interoperability by defining this rule or would be creating an unnecessary limitation?

My guess is that it would be an improvement, if only in the sense of making sure people use a predictable and easy-to-automate naming rules. But I'm not ideologically attached to the idea.


-- pmj

[RH Becker]

A big +1 on offering any sort of guidance on this issue. Even a white list of acceptable interpretations would be better than leaving it unaddressed.

Pretty much anyone attempting to adhere to PSRs is eventually going to wonder about this issue, repeat the same research dozens have done before them, and arrive at the frustrating conclusion of not knowing what to do.