Everything

php

Home » Project » Newsgroups » php.internals » StudlyCaps »

StudlyCaps

php.internals

Andi Gutmans

22 years ago

Hey,

I think we should come to closure on this discussion because it's becoming
hard to catch up with.
I'd like to finalize this issue for PHP (the C part) so that we can release
Beta 3. I think what PEAR does is really up to the PEAR dev team (although
I think it would be nice for them to be consistent with PHP itself).
The facts are the following:
a) Existing PHP functions use underscores.
b) Some external object models such as Java use StudlyCaps.

The immediate decision we have to make is if PHP's OOP functionality (class
names and method names) use underscores or studly caps.
I think for (b)
(interfacing with external object models) the answer is obvious. Do what
you need to do to expose the external object model, and thus use StudlyCaps
where applicable. That's kind of obvious IMO. If the external object model
has underscores then use that.

However, I think what we do with PHP's object model is not that obvious.
Although I'm quite indifferent to these when I program (I usually use the
most popular method with the language I'm using) I think there are two
advantages for using underscores:
a) functions already use them thus we are consistent across the board
(something we historically don't excel in).
b) StudlyCaps doesn't know how to deal with one character words such as
IAmAndi. which would be something like i_am_andi in underscores. You often
find yourself having to do two capitol letters one after another and it
ruins the whole thing. The same thing happens with acronyms, for example,
PHPObject (no differentiation between PHP and Object).

I think that even if some OOP developers prefer the studly caps, using
underscores might even have an advantage of differentiating between PHP
methods and the user's methods.
Let's not turn this into a religious war. I think everyone here understands
the pros/cons. Let's try and reach a decision quickly and make sure we
adopt it, because indecision is worse than making the wrong decision :)

I apologize for the long letter. Please don't copy me :)
Andi

George Schlossnagle

22 years ago

My vote is on StudlyCaps for class method and attribute names.  This is
the standard in many OO languages (SmallTalk, C#, Java - as a
parenthetical I don't think that SmallTalks adoption of StudlyCaps (one
of the first I'm aware of) had anything to do with _ rendering), and
while we do not need to mimic other languages, adopting common
conventions is a good thing.

Robert Cummings

22 years ago

On Wed, 2003-12-03 at 15:58, George Schlossnagle wrote:

> My vote is on StudlyCaps for class method and attribute names.  This is
> the standard in many OO languages (SmallTalk, C#, Java - as a
> parenthetical I don't think that SmallTalks adoption of StudlyCaps (one
> of the first I'm aware of) had anything to do with _ rendering), and
> while we do not need to mimic other languages, adopting common
> conventions is a good thing.

+1 for studlyCaps -- contrast IAmAndi versus nameIsAndi, the chosen
variable name makes all the difference.

Cheers,
Rob.

--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting  |
| a powerful, scalable system for accessing system services  |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for       |
| creating re-usable components quickly and easily.          |
`------------------------------------------------------------'

Hartmut Holzgraefe

22 years ago

Robert Cummings wrote:

> +1 for studlyCaps -- contrast IAmAndi versus nameIsAndi, the chosen
> variable name makes all the difference.

-1 on that argument as now the CS dictates what names you may chose
which should be the other way round IMHO

--
Hartmut Holzgraefe  <hartmut@php.net>

Robert Cummings

22 years ago

On Thu, 2003-12-04 at 05:07, Hartmut Holzgraefe wrote:

> Robert Cummings wrote:
> > +1 for studlyCaps -- contrast IAmAndi versus nameIsAndi, the chosen
> > variable name makes all the difference.
>
> -1 on that argument as now the CS dictates what names you may chose
>     which should be the other way round IMHO

It doesn't dictate what names you may choose, but for those who think
IAmAndi lacks aesthetics, then for such people perhaps another choice
would have been better. I was  merely pointing out that there are plenty
of alternate choices thus weakening the argument for blunderscore
separation based on the IAmAndi case.

Cheers,
Rob.

--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting  |
| a powerful, scalable system for accessing system services  |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for       |
| creating re-usable components quickly and easily.          |
`------------------------------------------------------------'

Ronald Chmara

22 years ago

On Dec 4, 2003, at 5:24 AM, Robert Cummings wrote:

> On Thu, 2003-12-04 at 05:07, Hartmut Holzgraefe wrote:
>> Robert Cummings wrote:
>>> +1 for studlyCaps -- contrast IAmAndi versus nameIsAndi, the chosen
>>> variable name makes all the difference.
>> -1 on that argument as now the CS dictates what names you may chose
>>     which should be the other way round IMHO
> ItDoesn'tDictateWhatNamesYouMayChoose,
> ButForThoseWhoThinkIAmAndiLacksAesthetics,
> ThenForSuchPeoplePerhapsAnotherChoiceWouldHaveBeenBetter.
> IWasMerelyPointingOutThatThereArePlentyOfAlternateChoicesThusWeakeningT
> heArgumentForBlunderscoreSeparationBasedOnTheIAmAndiCase.
> Cheers,
> Rob.

I'm_not_sure_why,
but_I_cannot_quickly_and_easily_figure_out_what_you_mean_to_say..

;-)

-Bop

Ronald Chmara

22 years ago

On Dec 4, 2003, at 5:47 AM, Ronald Chmara wrote:

> I'm_not_sure_why,
> but_I_cannot_quickly_and_easily_figure_out_what_you_mean_to_say..

The cute dig aside, common words are quickly read based on mental
assumptions of word "shapes", and word "breaks" Letter capitalization
means a new sentence, or proper noun, to most english speakers.. The
underscore is easily ignored as a "break" sign in english, hence, the
cheat. Studly caps could be more effective if only nouns had caps, but
CS folks aren't often social-language studies fans, and they cap each
word. OO conventions seem straight out of a language without word
breaks, beyond a new capital for each new word.

*shrug*

If OO folks can't adopt traditional code, lets bring the code to them,
and allow MysqlExec and mysql_exec... just strip the "_". If it's
slower, well, traditionally OO folks are happy to lose performance to
gain OO.

-Bop

Michael Walter

22 years ago

George Schlossnagle wrote:

> My vote is on StudlyCaps for class method and attribute names.  This is
> the standard in many OO languages (SmallTalk, C#, Java - as a
> parenthetical I don't think that SmallTalks adoption of StudlyCaps (one
> of the first I'm aware of) had anything to do with _ rendering), and
> while we do not need to mimic other languages, adopting common
> conventions is a good thing.

On the other hand, there are Common Lisp (foo-bar-baz), Python (mostly
foobarbaz) and Ruby (mostly foo_bar_baz).

George Schlossnagle

22 years ago

On Dec 3, 2003, at 5:14 PM, Michael Walter wrote:

> George Schlossnagle wrote:
>> My vote is on StudlyCaps for class method and attribute names.  This
>> is the standard in many OO languages (SmallTalk, C#, Java - as a
>> parenthetical I don't think that SmallTalks adoption of StudlyCaps
>> (one of the first I'm aware of) had anything to do with _ rendering),
>> and while we do not need to mimic other languages, adopting common
>> conventions is a good thing.
> On the other hand, there are Common Lisp (foo-bar-baz), Python (mostly
> foobarbaz) and Ruby (mostly foo_bar_baz).

To be pedantic, the Python style guide
(http://www.python.org/peps/pep-0008.html) specifies class names to be
StudlyCaps and method names to be either underscore-delimited or
StudlyCaps, at the authors leisure.  Of course, PHP is not Python.

George

Michael Walter

22 years ago

George Schlossnagle wrote:

>> On the other hand, there are Common Lisp (foo-bar-baz), Python (mostly
>> foobarbaz) and Ruby (mostly foo_bar_baz).
>
>
> To be pedantic, the Python style guide
> (http://www.python.org/peps/pep-0008.html) specifies class names to be
> StudlyCaps and method names to be either underscore-delimited or
> StudlyCaps, at the authors leisure.  Of course, PHP is not Python.

The latter being my real point :) I don't really have an opinion on the
subject (I'm fine with either style, as long as it's *consistent*), but
I felt like pointing out that there isn't really one standard convention
(as people might get the impression) even if you just consider languages
supporting OO.

Cheers,
Michael

Cristiano Duarte

22 years ago

I'm using double-underscores "__" to make autoloading of "fake packages" possible.
An example with StudlyCaps:
org__phporb__compiler__IdlCompiler

With underscores:
org__phporb__compiler__idl_compiler

I guess the first is better but I can live with the second.

IMHO we shouldn't have exceptions. If the DOM extension (and many others)
must use StudlyCaps (because of W3C specifications), all OO-based extension or
code should use too.
We can live with a CS for procedural and other CS for OOP.

Cristiano Duarte

Moriyoshi Koizumi

22 years ago

If the votes already takes place, I vote on studlyCaps as a
recommendation for PHP OO API, because of consistency with the
existing PEAR conventions.

I like underscore_delimited_style, but embracing two different
standards will definitely disgust not a few number of people.
Neither Readability nor familiarity does matter here.

Moriyoshi

Derick Rethans

22 years ago

On Thu, 4 Dec 2003, Moriyoshi Koizumi wrote:

> If the votes already takes place, I vote on studlyCaps as a
> recommendation for PHP OO API, because of consistency with the
> existing PEAR conventions.
>
> I like underscore_delimited_style, but embracing two different
> standards will definitely disgust not a few number of people.

haha, with these suckyCaps we have two different styles for core-php
functions; that's worse and that's what we *should* care about.

Derick

Ulf Wendel

22 years ago

Derick Rethans wrote:

> haha, with these suckyCaps we have two different styles for core-php
> functions; that's worse and that's what we *should* care about.

+1

And we gain a simple rule of thumb with underscores:

underscores => build-in functionality => referr to php.net/function_name
study => user supplied stuff => referr to pear.php.net/ or example.com/

Ulf

Pierre-Alain Joye

22 years ago

On Thu, 04 Dec 2003 12:09:00 +0100
Ulf Wendel <ulf.wendel@phpdoc.de> wrote:

> Derick Rethans wrote:
> > haha, with these suckyCaps we have two different styles for core-php
> > functions; that's worse and that's what we *should* care about.
>
> +1
>
> And we gain a simple rule of thumb with underscores:
>
> underscores => build-in functionality => referr to
> php.net/function_name study => user supplied stuff => referr to
> pear.php.net/ or example.com/

Absolutely wrong, method overload makes this assumption wrong.

Marcus Börger

22 years ago

Hello Andi,

i am pro studlyCaps.
1st it eases PEAR development towards php5.
2nd we choose not to do so as we couldn't show errors and all in original
casing, now we can we decided to use studlyCaps and we agreed upon even in
our CODING_STYLE (and we did whether or not that rule was removed today).
3rd using different naming conventions in procedural and oo code seems to be
a pro from my point of view, too.

--
Best regards,
Marcus                            mailto:helly@php.net

Derick Rethans

22 years ago

On Wed, 3 Dec 2003, Marcus Boerger wrote:

> 2nd we choose not to do so as we couldn't show errors and all in original
> casing, now we can we decided to use studlyCaps and we agreed upon even in
> our CODING_STYLE (and we did whether or not that rule was removed today).

That's bollocks. I put that 'rule' in after the PEAR meeting; it had
NOTHING to do with any discussion on the internals@ list.

Derick

Sascha Schumann

22 years ago

> 3rd using different naming conventions in procedural and oo code seems to be
> a pro from my point of view, too.

What is the perceived advantage here?

Do you type "->" and immediately forgot what follows that?

This really is no argument in the context of PHP (no implicit
binding of functions) or Java (no global functions).

- Sascha

Pierre-Alain Joye

22 years ago

+1 on studlyCaps

pierre

Georg Richter

22 years ago

I'm -1.

And for ext/mysqli which supports OO, studlyCaps would make life harder, to
migrate "old" php4 scripts to PHP5 and ext/mysqli.

How about an additional configure option --with-studly-caps (disabled by
default) and defining some additional aliases?

Georg

Olivier Hill

22 years ago

Georg Richter wrote:

>
> How about an additional configure option --with-studly-caps (disabled by
> default) and defining some additional aliases?

Ouch... That would render code written from one place unusable on
another server..

Oliver

--
GB/E/IT d+ s+:+ a-- C++$ UL++++$ P++++ L+++$ E- W++$ N- ?o ?K w--(---)
!O M+$ V- PS+ PE- Y PGP t++ 5-- X+@ R- tv++ b++(+++) DI++++ D+ G++ e+>++
h(*) r y+(?)

Moriyoshi Koizumi

22 years ago

On 2003/12/04, at 7:14, Georg Richter wrote:

> How about an additional configure option --with-studly-caps (disabled
> by
> default) and defining some additional aliases?

When we ought to have it, it must be --withStudylyCaps as well :)

Moriyoshi

Sascha Schumann

22 years ago

-1 on embracing studlyCaps in the context of PHP itself.

(Note: studlyCaps originated with a OO language, namely
Smalltalk, but it is not pervasive in OO land.  If you don't
believe me, just look at the STL.  You won't find any
uglyCaps over there.)

- Sascha

Michael Walter

22 years ago

Sascha Schumann wrote:

>     -1 on embracing studlyCaps in the context of PHP itself.
>
>     (Note: studlyCaps originated with a OO language, namely
>     Smalltalk, but it is not pervasive in OO land.  If you don't
>     believe me, just look at the STL.  You won't find any
>     uglyCaps over there.)
>
>     - Sascha
>

On the other hand, STL isn't really typical "OO land", but more a
library that uses OO for pragmatic reasons as much as it uses functional
style for pragmatic reasons. It is consistent, though, which is what I
desire most, nonetheless of the final choice.

Derick Rethans

22 years ago

Andi,

I'm -1 too because I want PHP being consistently have _ in
method/function names. (Another reason is to see the difference between
core and user code as Ulf pointed out).

Derick

Markus Fischer

22 years ago

On Wed, Dec 03, 2003 at 11:23:05PM +0100, Derick Rethans wrote :

> Andi,
>
> I'm -1 too because I want PHP being consistently have _ in
> method/function names. (Another reason is to see the difference between
> core and user code as Ulf pointed out).

Since every man and his cow already gave a vote, I'll do so too and
vote -1 for theCapsStyle in PHP itself. However, I think e.g. the
DOM extension should be left at what the W3C suggested (other
extension my need exceptions too).

I like the initial argument brought up by Mr. Wendel, namely to
easily differentiate between PHP method calls and userland written
method calls.

- Markus (and his cow)

Michael Walter

22 years ago

Markus Fischer wrote:

> [...]
> 	I like the initial argument brought up by Mr. Wendel, namely to
> 	easily differentiate between PHP method calls and userland written
> 	method calls.
>
> 	- Markus (and his cow)

How is this an advantage?

Cheers,
Michael

Melvyn Sopacua

22 years ago

On Wednesday 03 December 2003 23:35, Michael Walter wrote:

> Markus Fischer wrote:
>  > [...]
> >
> > 	I like the initial argument brought up by Mr. Wendel, namely to
> > 	easily differentiate between PHP method calls and userland written
> > 	method calls.
> >
> > 	- Markus (and his cow)
>
> How is this an advantage?

FWIW: it's not only an advantage, it's the reason I strive to use studlyCaps
in my userland functions - because they will never clash on the next php
upgrade (and the whole image* functions is a pain in the butt in that area).
What happens if a php provided object I extended chooses to implement the
same method and call it internally, expecting different results? Upgrading is
enough hasstle.

My 2c + a cow.

--
Melvyn

=======================================================
FreeBSD sarevok.idg.nl 5.2-BETA FreeBSD 5.2-BETA #0: Wed Dec  3 20:13:44 CET
2003     root@sarevok.webteckies.org:/usr/obj/usr/src/sys/SAREVOK_NOACPI
i386
=======================================================

Michael Walter

22 years ago

Melvyn Sopacua wrote:

> On Wednesday 03 December 2003 23:35, Michael Walter wrote:
>
>>Markus Fischer wrote:
>> > [...]
>>
>>>	I like the initial argument brought up by Mr. Wendel, namely to
>>>	easily differentiate between PHP method calls and userland written
>>>	method calls.
>>>
>>>	- Markus (and his cow)
>>
>>How is this an advantage?
>
>
> FWIW: it's not only an advantage, it's the reason I strive to use studlyCaps
> in my userland functions - because they will never clash on the next php
> upgrade (and the whole image* functions is a pain in the butt in that area).
> What happens if a php provided object I extended chooses to implement the
> same method and call it internally, expecting different results? Upgrading is
> enough hasstle.
>
> My 2c + a cow.

Ah, I understand. Never got into former problems as I prefix my
functions/classes with a package prefix. The latter point is
interesting. Although it's true, I think you're just "moving" the
problem into user-space, as it's an inherit "problem" of the language
(no parametric polymorphism, no "non-virtual" calls, in c++
terminology). Like, if you have that 3rd party PHP library, and you
inherit from it, you might as well run into problems if it uses
studlyCaps. It definately removes the problem for built-in php
functionality, though, I completely agree on that.

Cheers,
Michael

Andi Gutmans

22 years ago

At 11:35 PM 12/3/2003 +0100, Michael Walter wrote:

>Markus Fischer wrote:
> > [...]
>>         I like the initial argument brought up by Mr. Wendel, namely to
>>         easily differentiate between PHP method calls and userland written
>>         method calls.
>>         - Markus (and his cow)
>
>How is this an advantage?

You easily see what is taken from the language and what is user-land code.

Andi

Michael Walter

22 years ago

Andi Gutmans wrote:

> At 11:35 PM 12/3/2003 +0100, Michael Walter wrote:
>
>> Markus Fischer wrote:
>> > [...]
>>
>>>         I like the initial argument brought up by Mr. Wendel, namely to
>>>         easily differentiate between PHP method calls and userland
>>> written
>>>         method calls.
>>>         - Markus (and his cow)
>>
>>
>> How is this an advantage?
>
>
> You easily see what is taken from the language and what is user-land code.

Yeah, obviously. But what exactly do I gain from that? The only thing I
could figure is that when you see an unknown function, you can
immediately realize whether to grep the repository, or look on
php.net/foo (if course unless using a decent editor). This has never
really been a problem for me, though, hence the question. I do realize
though, that it might slightly increase beginner-friendliness - is that
the reasoning behind that point?

Michael

Lukas Smith

22 years ago

> From: Andi Gutmans [mailto:andi@zend.com]
> Sent: Wednesday, December 03, 2003 11:43 PM

> At 11:35 PM 12/3/2003 +0100, Michael Walter wrote:
> >Markus Fischer wrote:
> > > [...]
> >>         I like the initial argument brought up by Mr. Wendel, namely to
> >>         easily differentiate between PHP method calls and userland
> written
> >>         method calls.
> >>         - Markus (and his cow)
> >
> >How is this an advantage?
>
> You easily see what is taken from the language and what is user-land code.

Err but OO code is different than function code because of inheritance.
Separating core and userland code like this is absolutely ludicrous because
then you don't even need to use OO to begin with. I mean then you might as
well stick with functions which isn't what Ulf wants (that's why I was so
surprised to see Ulf suggesting something like this).

Regards,
Lukas

Pierre-Alain Joye

22 years ago

On Thu, 04 Dec 2003 00:42:40 +0200
Andi Gutmans <andi@zend.com> wrote:

> You easily see what is taken from the language and what is user-land
> code.

This argument is as non revelant as the aesthetic one.

internal:
class polygon {
function calc_barycenter()
{
}
}

php script:
class mypoly extends polygon{
function calc_barycenter()
{
}
}

$pl = new mypoly();
$pl->calc_barycenter(); // Is it a userland function?

.....

any other __objective__ argument?

pierre

Sascha Schumann

22 years ago

On Thu, 4 Dec 2003, Pierre-Alain Joye wrote:

> On Thu, 04 Dec 2003 00:42:40 +0200
> Andi Gutmans <andi@zend.com> wrote:
>
>
> > You easily see what is taken from the language and what is user-land
> > code.
>
> This argument is as non revelant as the aesthetic one.

One of the largest cost in software development is
maintenance.  One key factor regarding maintainability is
readability and understandability.  These issue cannot be
simply dismissed as irrelevant as you try to make it.

Of course, it is always easier to simply dismiss arguments
which don't support your point.  The price? Your
credibility.

- Sascha

Pierre-Alain Joye

22 years ago

On Thu, 4 Dec 2003 10:56:42 +0100 (CET)
Sascha Schumann <sascha@schumann.cx> wrote:

>     One of the largest cost in software development is
>     maintenance.  One key factor regarding maintainability is
>     readability and understandability.  These issue cannot be
>     simply dismissed as irrelevant as you try to make it.

I have to agree. But that does not match the readability argument told
here, as the readability (subjective) enhancement is so small regarding
to the additionnal work due to non studlyCaps internal *methods*.

However I fully agree with you when you say that should be anyway up to
the extension maintainers (ie a binder requering _ like mysql). That's
why I rather prefer to set a recommandation (to be used by default) and
, only if _required_ for easyness/technical reasons, use the alternative
naming.

>     Of course, it is always easier to simply dismiss arguments
>     which don't support your point.  The price? Your
>     credibility.

.

pierre

Derick Rethans

22 years ago

On Thu, 4 Dec 2003, Pierre-Alain Joye wrote:

> On Thu, 4 Dec 2003 10:56:42 +0100 (CET)
> Sascha Schumann <sascha@schumann.cx> wrote:
>
>
> >     One of the largest cost in software development is
> >     maintenance.  One key factor regarding maintainability is
> >     readability and understandability.  These issue cannot be
> >     simply dismissed as irrelevant as you try to make it.
>
> I have to agree. But that does not match the readability argument told
> here, as the readability (subjective) enhancement is so small regarding
> to the additionnal work due to non studlyCaps internal *methods*.

I don't see the "additional work" part here...how is it going to create
extra work for the PHP developers?

Derick

Christian Schneider

22 years ago

Markus Fischer wrote:

> 	Since every man and his cow already gave a vote, I'll do so too and
> 	vote -1 for theCapsStyle in PHP itself. However, I think e.g. the
> 	DOM extension should be left at what the W3C suggested (other
> 	extension my need exceptions too).

I agree with Markus.

- Chris (I've no cow yet so not voting right but still an opinion)

Sebastian Bergmann

22 years ago

Markus Fischer wrote:

> Since every man and his cow already gave a vote, I'll do so too and
> vote -1 for theCapsStyle in PHP itself. However, I think e.g. the
> DOM extension should be left at what the W3C suggested (other
> extension my need exceptions too).

So much for consistency ...

--
Sebastian Bergmann
http://sebastian-bergmann.de/                   http://phpOpenTracker.de/

Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/

Ilia A.

22 years ago

-1

*Caps syntax is harder to read & use compared to the underscore based system,
which we already use. Having 2 separate naming conventions is confusing and
difficult and you end up with the code which will mix & match both of them
resulting in confusing and difficult to read code.

Ilia

Andi Gutmans

22 years ago

At 11:14 PM 12/3/2003 +0100, Georg Richter wrote:

>I'm -1.
>
>And for ext/mysqli which supports OO, studlyCaps would make life harder, to
>migrate "old" php4 scripts to PHP5 and ext/mysqli.
>
>How about an additional configure option --with-studly-caps (disabled by
>default) and defining some additional aliases?

No matter what the decision, I definitely don't want any configure options
and no INI options.

Andi

Andi Gutmans

22 years ago

I think you misunderstood what I said. I said that I support underscore
naming, but it should be allowed in extensions which follow a specific
standard such as DOM (W3C), obviously Java connectivity (that's really not
under our control anyway because it depends on how you write your Java code).
Most extensions, such as mysqli, don't fall in this category and should
thus use underscores.

Hope I made myself clearer now.

Andi

At 05:50 PM 12/3/2003 -0500, Ilia Alshanetsky wrote:

Derick Rethans

22 years ago

On Thu, 4 Dec 2003, Andi Gutmans wrote:

> I think you misunderstood what I said. I said that I support underscore
> naming, but it should be allowed in extensions which follow a specific
> standard such as DOM (W3C), obviously Java connectivity (that's really not
> under our control anyway because it depends on how you write your Java code).
> Most extensions, such as mysqli, don't fall in this category and should
> thus use underscores.
>
> Hope I made myself clearer now.

Yup, and I agree 101% percent with you.

Derick

Jani Taskinen

22 years ago

I'm -1 for suckyCaps.

--Jani

p.s. Why not a mix, e.g. PHP_Object =)

Sebastian Bergmann

22 years ago

Andi Gutmans wrote:

> The facts are the following:
> a) Existing PHP functions use underscores.

PHP's internal *function names* should use _ to delimit between
words.

> b) Some external object models such as Java use StudlyCaps.

And this what we should *consistently* adopt for the naming of PHP's
internal *method names*.

So, of course, I am +1 for studlyCaps. But regardless of a pro/con
decision on studlyCaps the result must be consistent.

--
Sebastian Bergmann
http://sebastian-bergmann.de/                   http://phpOpenTracker.de/

Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/