There's nothing in the documentation that discusses variable naming
conventions, only function/method names. Personally, I don't make the leap
that just because functions are namedLikeThis that variables should be also.
In fact, as I said last week, I feel exactly the opposite -- and until the
day that the Coding Standards are updated to specifically address variable
names, I will not consider my choice to name_variables_like_this to be
incorrect, invalid, or not recommended.
I think that, even if it's not state explicitly, people using PEAR packages have come to expect humpBack because hundreds of variables and functions are all named that way. It's this expectation that I use as a basis for my argument.
If I've used three or four PEAR packages I've come to expect fooBar() and thisVar. If I install a new package I can make guesses as to what to look for or try.
This is EXACTLY the type of argument that so many people make against PHP - that the API and naming schemes are inconsistent (ie. isset() vs. is_null()).
At the VERY least the CS should say "Choose a variable scheme and stick with it". I, personally, think it should further say "use humpBack", but that's only because the vast majority of the packages already use that and PEAR users have come to expect humpBack. Either way, though, coders should choose this_var or thisVar and stick with it within their packages.
Private/protected should not fall under CS at all of course.
--Joe
-Clay
--Killersoft.com
--PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php