According to "Pro Drupal Development" p. 482:

"Module names should never include an undrscore...."


Michelle’s picture

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


yhager’s picture

Status: Active » Postponed (maintainer needs more info)

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

mattyoung’s picture

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'.

yhager’s picture

Project: Magic Tabs » infrastructure
Version: 6.x-1.0 »
Component: Code » CVS
Status: Postponed (maintainer needs more info) » Active

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, CVS server should enforce this.
I'm moving this issue to infrastructure.

yhager’s picture

Title: The module name should not be 'magic_tab', should be 'magictab' » Module names should not contain an underscore(_)
dww’s picture

Status: Active » Closed (won't fix)

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


Gábor Hojtsy’s picture

Agreed with dww.

Michelle’s picture

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.


Morbus Iff’s picture

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.

alexanderpas’s picture

Title: Module names should not contain an underscore(_) » Disallow Module names containing core hook prefixes
Status: Closed (won't fix) » Active

for consideration:

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

moshe weitzman’s picture

Status: Active » Closed (won't fix)

still no.

mattyoung’s picture

Status: Closed (won't fix) » Active

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.

alexanderpas’s picture

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.

dww’s picture

Title: Disallow Module names containing core hook prefixes » Module names should not contain an underscore(_)
Status: Active » Closed (won't fix)

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.

deekayen’s picture

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.

jvandyk’s picture

To be fair, the workflow_access.module was not committed by me:

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.

Component: CVS » Other