[development] Module naming conventions (was Re: Naming the CVS abstraction module)

[Jakob Petsovits]

On Sunday, 10. June 2007, Angela Byron wrote:
> New thread, so we don't swamp poor Jakob's. :) Let's get consensus
> here and then update the coding standards.

I doubt if coding standards are going to work here at all.
The difficulty with this is that module names have to be decided at the very 
beginning of the project (or at least, before the first commit), and after 
that you cannot change the name anymore. At least not without being backed by 
some seriously influential admins like Derek or Andy ;)

A lot of modules is contributed by newcomers to the Drupal scene, and they 
need some time to get used to all the conventions and standards. If you look 
at the code of newly committed modules, in many cases it doesn't adhere to 
coding standards at all. That's not so much of a problem as you can still fix 
it afterwards, but with the short name of a module, you can't.
(Blame CVS, harhar.)

Also, we roughly got a 50/50 situation with respect to modules that are 
separated or not separated by underscores when it would possibly be 
appropriate. They'd seriously undermine the consistency if it's decided to 
come up with a standard here.

In short, I'm not yet convinced that it's a good idea to include stuff like 
this into the guidelines. Personally, I think the version without underscore 
looks way more slick and accessible than if you split the words, but if 
something is decided here, I'd of course go with that.

> The module name and the prefix will always match, except in the case
> where an underscore prefixes a function name, but again, that problem
> surfaces for both _mymodule_func and mymodule_func.
>
> Relying on the module name to NOT have underscores in it seems
> brittle and error-prone to me. There are underscores-o-plenty in
> http://cvs.drupal.org/viewcvs/drupal/contributions/modules/,
> regardless of what we actually decide the standard should be. :) If
> that means we need to make our utility functions more intelligent,
> then we should probably do that.

Agreed.