code style

Using Constants For Permission Names: WHY?

I keep seeing this sort of thing in so many modules:

define("MY_MODULE_PERM_ACCESS_WIDGETS", 'access widgets');
// Names changed to protect the guilty ;)

Am I missing something, or is this utterly pointless?

The only advantage I see is that you can change the permission string later on. But you actually can't change a permission string once you've made a release without an almighty amount of work in a hook_update_N()[*] to migrate users' existing permissions, so what is the point of using a constant apart from just creating shouty caps noise?

[*] Is there a helper function in core yet for migrating permission names during updates? There really should be.

Nodes As NIDs

Is it just me who finds this poor style and potentially confusing:

function my_function($nodes) {
  foreach (
$nodes as $nid) {
// do stuff

To me, a variable names $nodes will be an array of nodes -- that is, node objects. If it's an array of nids, I would call it $nids to avoid confusion about what we have there.

I'm curious if other people agree (in other words, is it worth my time writing a patch for core or will it just lead to bikeshedding?)

In general, though, I think it's a good idea for variables to be named in such a way that describes what they hold; also for the same data to have the same variable name as it travels through functions. In other words, avoid this:

function foo() {

bar($caterpillars) {


Unless there's a good reason, say if bar() is generic and can accept any animal. In which case, call its parameter $animals, obviously.

Subscribe to RSS - code style