Re: Naming convensions

On 8/3/2005 8:18 PM, Justin Patrin spake the following words: > On 8/3/05, Klaus Guenther <klaus@capitalfocus.org> wrote: > >>On 8/3/2005 7:40 PM, Stoyan Stefanov spake the following words: >> >> >>>Hi guys, >>> >>>I was just looking at the changelog for Net_Curl (Great job, BTW! >>>setOptions() and getInfo() were really needed). I saw this entry: >>> >>>- Fixed coding standards, which included variable name changes (ie. >>>http_headers to httpHeaders) >>> >>>I think both $some_var and $someVar are acceptable, there's no strict >>>rule for the variables stated here >>>http://pear.php.net/manual/en/standards.naming.php >>> >>>Is it OK for a PEAR package to use $some_var? >>> >>> >> >>My understanding is that it really shouldn't be OK, but some people do >>it anyway. However, you can't BC break in packages > 1.0.0-stable. So >>I'm not sure exactly what should be done here :) > > > I also agree. I think we should have one convention when it comes to > naming. This way we always know how something should be named and > it's not context-sensitive. > > However, internal vars are ok to change as long as they're not part of > the public API. This wouldn't be a BC break IMHO. Of course: private method/properties don't count toward BC. All that matters is the public API. >>>Another thing - the naming conventions doc state that global vars >>>should start with an underscore followed by the package name, like >>>$_PEAR_whatever or $_PEAR_destructor_object_list. But the example >>>(http://pear.php.net/manual/en/standards.sample.php) doesn't have an >>>underscore ($GLOBALS['NET_SAMPLE_Count'] = 0) and in addition it >>>capitalizes the package name and the first letter of the >>>after-package-name part. To me, this should be: >>>$GLOBALS['Net_Sample_count'] = 0; >>>because it is consistent with the package naming convention, the >>>$some_vars naming and the $_PEAR_destructor_object_list example, >>>mentioned in the naming convention manual entry >>>(http://pear.php.net/manual/en/standards.naming.php, very bottom) >>> >> >>Hmm. I don't use globals in my packages, but I think you're absolutely >>right here. >> > > Yep, you're probably right. I think that the package name is supposed > to be all caps, though.... Not so sure about that... I know that goes for constants (all caps), but globals? Klaus