Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » sudlyCaps »

sudlyCaps

php.internals

(Marcus Börger)

22 years ago
Hello internals, referring to paragraph 6 of our CODING_STYLES i changed my own spl extension and parts of SQLite which interact with spl. [6] Method names follow the 'studlyCaps' (also referred to as 'bumpy case' or 'camel caps') naming convention, with care taken to minimize the letter count. The initial letter of the name is lowercase, and each letter that starts a new 'word' is capitalized. Good: 'connect()' 'getData()' 'buildSomeWidget()' Bad: 'get_Data()' 'buildsomewidget' 'getI()' This change immediatly caused stormy discussion on IRC. Here is what i think: * nobodycanreadysudlycapsmethods <- can you read that? That is what our error messages and the reflection output will contain instead of the intended nobodyCanReadySudlyCapsMethods what isn't much better. Anyway PHP isn't simply capable of handling sudlyCaps since we need to input method names in lowercase. * When moving extensions from PHP4 to PHP5 we would sooner or later add newer features to their classes just like i did with SQLite. This does result in a mixture of the old and new naming conversion which is annoying. As the only consequence i think we should remove that part 6 from our CS. regards marcus
-- Best regards, Marcus mailto:helly@php.net

Sascha Schumann

22 years ago
> As the only consequence i think we should remove that part 6 from our CS.
Certainly. I did not even know it was there. - Sascha

Derick Rethans

22 years ago
On Thu, 4 Sep 2003, Marcus Börger wrote:
> As the only consequence i think we should remove that part 6 from our CS.
let's replace it with this: [6] Method names follow the same naming style as normal functions like "mysql_connect". Good: 'connect()' 'get_data()' 'build_some_widget()' Bad: 'get_Data()' 'buildSomeWidget()' 'getI()' Derick
-- "Interpreting what the GPL actually means is a job best left to those that read the future by examining animal entrails." ------------------------------------------------------------------------- Derick Rethans http://derickrethans.nl/ International PHP Magazine http://php-mag.net/ -------------------------------------------------------------------------

Sterling Hughes

22 years ago
The problem is this creates a difference with the PEAR classes and PEAR standards. I agree that on the whole using underscores is a better method, its my preference as well. But PEAR already made the decision to go with studlyCaps, and we should follow in suite (as they are the largest collection of OO classes for PHP, and tightly integrated with PHP). Its also important to consider that PEAR needs to extend internal classes and provide extra information (like the Exception class). We don't want them to have to alias every method to the compatible version for their needs. You also have the fact that most specified (standard) OO apis follow the studlyCaps notation (chregu mentioned DOM as an example, there are others). Conforming to these (or coming close as possible) is a good thing. Whether studlyCaps are nice or not is imho really irrellevant at this point. Its about following a naming standard, and the decision has already been made by PEAR. -Sterling On Thu, 2003-09-04 at 17:23, Derick Rethans wrote:
> On Thu, 4 Sep 2003, Marcus Börger wrote: > > > As the only consequence i think we should remove that part 6 from our CS. > > let's replace it with this: > > [6] Method names follow the same naming style as normal > functions like "mysql_connect". > > Good: > 'connect()' > 'get_data()' > 'build_some_widget()' > > Bad: > 'get_Data()' > 'buildSomeWidget()' > 'getI()' > > Derick > > > -- > "Interpreting what the GPL actually means is a job best left to those > that read the future by examining animal entrails." > ------------------------------------------------------------------------- > Derick Rethans http://derickrethans.nl/ > International PHP Magazine http://php-mag.net/ > -------------------------------------------------------------------------
-- We all agree on the necessity of compromise. We just can't agree on when it's necessary to compromise. - Larry Wall

Lukas Smith

22 years ago
> From: Marcus Börger [mailto:marcus.boerger@t-online.de] > Sent: Thursday, September 04, 2003 5:13 PM
> referring to paragraph 6 of our CODING_STYLES i changed my own spl > extension > and parts of SQLite which interact with spl. > > [6] Method names follow the 'studlyCaps' (also referred to as 'bumpy
case'
> or 'camel caps') naming convention, with care taken to minimize
the
> letter count. The initial letter of the name is lowercase, and
each
> letter that starts a new 'word' is capitalized. > > Good: > 'connect()' > 'getData()' > 'buildSomeWidget()' > > Bad: > 'get_Data()' > 'buildsomewidget' > 'getI()' > > This change immediatly caused stormy discussion on IRC. > Here is what i think: > * nobodycanreadysudlycapsmethods <- can you read that? That is what
our
> error messages and the reflection output will contain instead of the > intended nobodyCanReadySudlyCapsMethods what isn't much better. > Anyway PHP isn't simply capable of handling sudlyCaps since we need
to
> input method names in lowercase. > > * When moving extensions from PHP4 to PHP5 we would sooner or later
add
> newer features to their classes just like i did with SQLite. This
does
> result in a mixture of the old and new naming conversion which is > annoying. > > As the only consequence i think we should remove that part 6 from our
CS. PEAR has had their error messages all lowered cased since it's creation. I can only speak for the last 1,5 years were I don’t remember this ever being an issue that was brought up. Maybe something to consider is the fact that in OO you don’t have to have the "ext_" prefix and therefore most method names should only consist of 2 in rare cases 3 words. I just want to clarify what this means for PEAR. It means we have to change our CS, because otherwise we either have a mixed CS which sort of defeats the purpose or we have to wrap every object that we want to extend that is provided by an extension. This obviously means a mess beyond believe for PEAR. I know that there is no way to have studlyCaps being preserved in error messages without a huge performance hit since we have case insensitivity for function/method names. However aside from the other reasons I stated when I initially proposed this, I just wanted to make clear what this means. So is this really such a huge issue? Regards, Lukas

Christian Stocker

22 years ago
On 9/4/03 5:55 PM, Lukas Smith wrote:
>>From: Marcus Börger [mailto:marcus.boerger@t-online.de] >>Sent: Thursday, September 04, 2003 5:13 PM > > CS. > > PEAR has had their error messages all lowered cased since it's creation. > I can only speak for the last 1,5 years were I don’t remember this ever > being an issue that was brought up. Maybe something to consider is the > fact that in OO you don’t have to have the "ext_" prefix and therefore > most method names should only consist of 2 in rare cases 3 words. > > I just want to clarify what this means for PEAR. > It means we have to change our CS, because otherwise we either have a > mixed CS which sort of defeats the purpose or we have to wrap every > object that we want to extend that is provided by an extension. > > This obviously means a mess beyond believe for PEAR. > > I know that there is no way to have studlyCaps being preserved in error > messages without a huge performance hit since we have case insensitivity > for function/method names. However aside from the other reasons I stated > when I initially proposed this, I just wanted to make clear what this > means. > > So is this really such a huge issue?
Furthermore, ext/dom is already "studlyCapsed", 'cause there it made a lot of sense, since the DOM specs already use studlyCaps... Just as a remark. I personally do not care much about if studlyCaps or old_school_php_function_names. But I understand PEAR's point and ext/dom with studlyCaps is IMHO the way to go, even if PHP does not care about createDocument or createdocument or crEaTeDoCuMent.. chregu

Moriyoshi Koizumi

22 years ago
Related articles: http://marc.theaimsgroup.com/?l=php-dev&m=105299997308470&w=2 http://marc.theaimsgroup.com/?l=php-dev&m=104837776401767&w=2 Moriyoshi marcus.boerger@t-online.de (Marcus Börger) wrote: