Module names should not contain an underscore

LOL! You're going to be busy if you're planning on filing issues on the 1000+ modules that have underscores in their names. ;)

Michelle

May I ask why? What's wrong with the underscore?

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. ;)

Cheers,
-Derek

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.

Michelle

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().

still no.

let's look at these:
- hook_prepare
- hook_insert
- hook_delete
- hook_update
- hook_validate

conflicting modulename endings, when prefixed with any other module name:
- actions
- comment
- file
- image_style
- node
- node_type
- taxanomy_term
- taxanomy_vocabulary
- user

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.