Re: Naming convensions

On 8/3/05 9:46 PM Pacific Time, Joe Stump (joe@joestump.net) wrote: > 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. I don't have time tonight to do a full analysis of PEAR packages (would be really interesting, though!), but a scan through some of the core PEAR packages that are bundled with PHP, they _ALL_ use variable_names_like_this. PEAR.php PEAR/Common.php DB.php (see DB_Result class) XML/RPC.php Archive/Tar.php If these packages aren't the backbone of PEAR, and therefore the examples to follow for variable naming in PEAR, what would be? > 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()). I agree -- inconsistent names are a pain. I've been using PHP for 8 years and still have to check my cheat sheet regularly on function names AND argument order (needle, haystack? Or haystack, needle?) > At the VERY least the CS should say "Choose a variable scheme and > stick with it". I agree. > I, personally, think it should further say "use > humpBack", but that's only because the vast majority of the packages > already use that I'm not so sure that "vast majority" is accurate here. I've been popping open package files almost at random here for the last 15 minutes, and haven't found one with camelCase variable names yet. > and PEAR users have come to expect humpBack. How do we know this? I certainly haven't come to expect anything in variable names, and being a seasoned PHP person has trained me to double-check the API docs or the source. -Clay -- Killersoft.com