If you're referring to this in the coding standards: "Global Variables - If you need to define global variables, their name should start with a single underscore followed by the module/theme name and another underscore." It never occurred to me to interpret this for database columns. I read an implied "php" before global variables, thus global $example; // bad global $_mymodule_example; // good I even added a rule to coder to check for this, but had to add exclusions for a couple dozen core modules that didn't follow this convention. Doug Green 904-583-3342 www.douggreenconsulting.com Bringing Ideas to Life with Software Artistry and Invention... Providing open source software political solutions -----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Josh Koenig Sent: Wednesday, May 30, 2007 2:49 AM To: development@drupal.org Subject: Re: [development] $node namespace woes -- can we fix this in D6? The standard Moshe is talking about is somewhat implied here at the bottom in the naming convention section: http://drupal.org/coding-standards It should probably be explicitly spelled-out though in terms of stuffing data into node objects and the like. I think putting it in doxygen is critical. I real api.drupal.org 100 times a day. Handbook maybe once a week. :) I (heart) standards. -josh
On May 29, 2007, at 6:23 PM, Moshe Weitzman wrote:
thata the drupal convention, and IMO it works quite well.
undocumented conventions that aren't expressed in the code of core are worthless, IMHO.
Contrib modules are second class citizens and should always prefix their variables, form fields, node elements, etc. this system works very well, when you use it.
so, you advocate "luck" as the solution to this problem. ;) fair enough. however, if core doesn't do this itself, we have to mention this in the developer docs, preferably in a few places like the doxygen for nodeapi('load'), the drupal coding convetions, etc, etc. if that's really the only answer here, i'll volunteer to submit the issue to the documentation queue...
thanks, -derek
p.s. project* was written by core maintainers, and has been doing this wrong for over 5+ years. if we can't trust the core maintainer's own contribs to provide best practices for this, who can we trust? ;) hence the need for docs and vastly more awareness of this problem by the rest of us 2nd class citizens.
Josh Koenig, Partner josh@chapterthreellc.com AIM: chap3josh 1-888-822-4273