According to "Pro Drupal Development" p. 482:
"Module names should never include an undrscore...."
LOL! You're going to be busy if you're planning on filing issues on the 1000+ modules that have underscores in their names. ;)
May I ask why? What's wrong with the underscore?
From the book "Pro Drupal Development":
Module names should never include an underscore. To understand why, think of the following scenriao:
1. A developer create node_list.module that containts a function called node_list_all().
2. In the next version of Drupal, the core node module adds a function called node_list_all()--namespace conflict!
Basically, with the name 'magic_tabs', you are taking both namespaces 'magic' and 'magic_tabs'.
That's interesting - thanks.
Anyway, I am not going to change an existing module's name, as it is too much hassle for people who already installed it. I'll definitely consider this advice for new modules I write.
However, I beleive that, if this is important, drupal.org CVS server should enforce this.
I'm moving this issue to infrastructure.
The core coding standards oppose CamelCase.
Writingeverythingtogetherinonebigmess is impossible to read.
The only alternative that doesn't cause PHP syntax errors is _
Core should consider invoking hooks with [module_name]__[hook_name] (2 underscores) to avoid this problem.
Meanwhile, we will certainly not be configuring CVS to prevent underscores in module names. ;)
Agreed with dww.
Glad to hear it, dww. There are a lot of underscored modules out there and I've never heard of a conflict. For this to be a serious issue, there would have to be a module named "magic" that just happened to have a function called "magic_tabs_something" where the magic tabs module had that same something. And then both modules would need to be installed on the same site at the same time. Even with 4K modules, this kind of conflict is unlikely and could be dealt with simply by renaming the function.
Yeah, you know, I agree with the logic behind this, but don't intend to personally rename my modules, much less *change the way I name them in the future*. I, personally, feel that it should be worried about when a conflict actually happens, as that's far more palatable then lots of ugly-assed and munged module names.
for consideration: http://drupal.org/node/451152#comment-1613640
the Views module defines views_preprocess_comment(). Everything is alright, until someone wants to create the views_preprocess module. Once this module is enabled, that function magically becomes and implementation of hook_comment().
Won't fix in code is alright but there needs to be clear module naming convention spell out so we don't face conflicts.
I suggest a handbook page created to specify how module should be named.
>Writingeverythingtogetherinonebigmess is impossible to read.
If you consider 'Writingeverythingtogetherinonebigmess' as one word, you mind recognized it easily and you really don't need to parse it at all. Visually we only need the beginning and end of a word to recognize the pattern. And when you need to spell out the word when writing code, you mind knows what's in there and it's easy to spell it. Just like spelling wysiwyg. You can spell it naturally. So forbidding under bar in name space is fine.
let's look at these:
conflicting modulename endings, when prefixed with any other module name:
for example, the module field_actions can not exist due to namespace conflicts.
(field_delete & field_actions_delete vs. field_actions_delete & field_actions_actions_delete)
even if only one module implements the field_actions_delete, wrong hooks get fired at the wrong time.
Still no. If folks want to document a best practice, please take that up in the documentation issue queue. We're not going to be enforcing more rules for this, period. In the rare cases where there's a problem, take it up with the module maintainer(s).
Locking comments on this thread, since it should stay closed.
Just to reinforce the point about how unpractical that rule is, even John doesn't follow the no underscore rule. Check out workflow_access.module in the workflow project.
To be fair, the workflow_access.module was not committed by me: http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/workflow/wo...
Anyway, it's a best practice. A thing to strive for. A way of avoiding potential conflicts, however remote. It's not a regulation, and I we don't need regexes to enforce it, nor do I follow it religiously. But the conflicts do rear their ugly heads once in a while, and it's bitten me more than once, which is why I mentioned it in The Book.
This issue has no child issues.
Drupal is a registered trademark of Dries Buytaert.