Re: Function naming in the procedural world

On Thursday 11 June 2009 10:56:55 am Brian Moon wrote: > So, lets talk standards. *snip* > So, for Phorum, we use the format: > > {vendor}_{file}_{function}(); > > e.g. phorum_db_get_messages(); > > vendor = phorum > file = db (actual file name varies for db as we support several) > function = get_messages > > Now, this does not have a delimiter for when the function starts and the > prefix ends, but I think it reads very clear and is simple to > understand. I used this same scheme in Wordcraft. I used the prefix > for wc_ there for brevity. Perhaps once namespaces are widespread, we > can migrate to having our functions namespaced. Although, I am unclear > if I can use the same namespace in several files. I know it is one > namespace per file. But it is one file per namespace? Anyone know? > > For internal functions at dealnews.com, we skip the vendor part as it is > all dealnews code. > > fetch_vendors(); > > In this case for us, the "fetch" has meaning. "get" in dealnews talk > means get data from our main RDBMS and "fetch" means to get data from > our forward facing replicated RDBMS pool. Poor naming choices for > anyone not used to them, perhaps. > > How are others naming functions for internal use? That is similar to what Drupal does, although many of our functions have special naming because they are called dynamically. In fact I think the majority do. We've always had a function_name() standard as far as capitalization, as it matches PHP's internal naming convention. Classes haven't really been standardized until recently, and had some people using CamelCase and some using class_name, but with an increasing use of OOP in core we've adopted the ClassName::methodName() convention that is about as close to a de facto standard as anything I've seen, and is what PHP uses internally. I am gently leaning on those still using class_name::method_name() in contrib modules to get with the program. :-) For "hooks", which are functions called dynamically, the mandatory naming convention is: $module_$hookname, where both $module and $hookname could be multi-word with underscores. For API functions or direct callbacks, it's conventional and encouraged to use the module name as the prefix. The end result is that the "taxonomy" module consists primarily of functions named "taxonomy_something", whether they're called directly or not. For core API functions, some have a drupal_ prefix and some do not. I'll be honest and say that I do not actually know if there is a standard for when to do so. :-) Some subsystems like the database always have a db_ prefix, but others like the theme system do not, as it would actually conflict with the magic naming that provides so much of Drupal's functionality. Naming functions for compatibility with 3rd party systems has never really been a priority. -- Larry Garfield larry@garfieldtech.com