code style

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

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.

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

<?php
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:

<?php
function foo() {
  bar($ponies);
}

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