[development] $node namespace woes -- can we fix this in D6?
douggreen at douggreenconsulting.com
Wed May 30 13:56:23 UTC 2007
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
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.
Bringing Ideas to Life with Software Artistry and Invention...
Providing open source software political solutions
From: development-bounces at drupal.org [mailto:development-bounces at drupal.org]
On Behalf Of Josh Koenig
Sent: Wednesday, May 30, 2007 2:49 AM
To: development at 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:
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.
> 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...
> 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 at chapterthreellc.com
More information about the development