Coding best practices discussion : named identifiers please

(dunno if this is usability or core really)

Messing around with the code, I've noticed an annoying paucity of nice identifiers. Too often information is indexed by integer when it could have perfectly well have been a nice label.

hook_block() is my first target. I scratch my head over the meaning of $delta (bad variable name too - it's not changing it's selecting)

So each different block type a module declares has an integer index. We have "Module Block #1", "Module Block #2" etc. I guess the design decision made sense once upon a time, but no more. I can have "Tree Block" and "List Block" instead!

My block declarations now look like this: (pseudo)

function metadata_blocks_block($op = 'list', $block_label = 0, $edit=array()) {
  switch($op){
    case 'list':
      $blocks['treeblock']['info'] = t('Display metadata in a tree'); 
      $blocks['listblock']['info'] = t('Display metadata in a list'); 
      return $blocks;
    break;
  else if ($op == 'view') { 
    switch( $block_label) { 
      case 'treeblock' : 
        $block['content'] = mymodule_display_tree(); 
        break; 
      case 'listblock: 
        $block['content'] = mymodule_display_list(); 
        break; 
    } 
  return $block; 
}

Most amazingly, this doesn't break anything anywhere, it just works.

Bonus is that the admin sections make sense : admin/block/configure/metadata_blocks/treeblock instead of ...metadata_blocks/1

Big bonus is that I can now impliment a 'call_block_by_name("treeblock")' function to access these blocks programatically.

Real intent was for me to be able to create block instances on the fly (like block.module does) and then find them again later. This now works too.

OK, so much for hook_block - it's only really an issue for coders like me, but how about elsewhere?

Why are taxonomy terms not indexed by their own term?

Wouldn't it be nice to replace
taxonomy/term/4+5
with
taxonomy/term/development+hacking ?

Wouldn't it be nicer in snippets or templates to be able to call
taxonomy_select_nodes(array("personal"));
rather than
taxonomy_select_nodes(array("17")); or do a whole bunch of lookups to the id of the term you are looking for?

OK, I know that with different vocabularies and stuff there is a 5% chance you'll want to use the same word in two places, but a work-around for that for that is trivial.

Flexinode is also guilty

I got dumped into a project where they had already defined flexinodes to expose/store a bunch of fields. Yep, the data was being retained and managed OK, and they want me to fix up the template so this bit of information goes there, etc etc. So I go looking for the info, and find it's called $node->flexifield_17 or something equally stupid.

It would have been trivial to have labelled the damn index at create time by making a camelCase version of the field name or something, so I can call $node->usefulName instead.
... because this is a dev site, to be rebuilt (not cloned) elsewhere, the flexinode will have to be built in EXACTLY THE SAME ORDER again ... including the fields we took out later!

Thoughts?

So, is there a good reason to not carry on what I'm doing with the hook_block?
Do you really think it makes any difference to the database efficiency (or PHP indexed arrays) to index on int rather than string?

Could this sort of readable code methodology be sneaked into the system without breaking anything? I'm convinced flexinode/fleximax could do it without breaking its API at all, and suddenly the theming would be 3x easier.
Almost anywhere a numbered array is used, there is space for extra information to be squeezed in, whether it's used or not.

.dan.