Re: Function naming in the procedural world

Brian Moon wrote: > So, lets talk standards. > > We have always used a modified PEAR standard for most things. One of > the things we modify is function naming. > > PEAR states: > > "Global functions should be named using the "studly caps" style (also > referred to as "bumpy case" or "camel caps"). In addition, they should > have the package name as a prefix, to avoid name collisions between > packages. The initial letter of the name (after the prefix) is > lowercase, and each letter that starts a new "word" is capitalized. An > example: XML_RPC_serializeData()" > > Now, for a repository like PEAR I can understand this. They want > package information delimited by the _ and then the functions base name > to use studly caps. But, in a non-OOP lib or non-repository, we found > this to be very verbose and very... well... ugly. It is also counter to > the (now) standards for PHP internal function naming: > > "Function names for user-level functions should be enclosed with in the > PHP_FUNCTION() macro. They should be in lowercase, with words underscore > delimited, with care taken to minimize the letter count. Abbreviations > should not be used when they greatly decrease the readability of the > function name itself." > > So, you end up with inconsistent reading code. I mean, older functions > in PHP that used camel case and seemingly random variable order cause > enough confusion. > > So, for Phorum, we use the format: > > {vendor}_{file}_{function}(); This would translate well into <?php namespace vendor\file; function functionname(){} ?> However, I wonder if you are in essence doing the exact same thing as the proposed namespace naming for OOP? i.e. {vendor}_{package}_function You just define package as the file containing the function. Greg