Maya Naming Conventions

(updated on 2014-09-10)

Summary

• L_arm_1_upper_joint  >  L_arm_2_lower_joint
• Prefix = Region: Side ("L_..." / "R_..." / none for center) + region ("...arm_", "spine_", ...)
• Middle = Hierarchy numbering starting at 1 (not 0) followed by descriptive string ("...1_upper...", "...2_lower...")
• Suffix = Nodetype: Default Maya nodenames ("..._blendColors", "..._multiplyDivide", ...)

Motivation

This is a simple naming convention that currently seems the most logical to me, after having used different ones of myself and coworkers in the past. The main goals are:

1. Readability (from the name know what it is and where it is used. But not too long)
2. Simplicity (easy to learn, avoid confusion, hard to make mistakes, few exceptions)
3. Functionality (easy to work with: string search / filter)
   

Prefix = Region ("L_arm_...", "spine_...")

If a region is in the center and/or only appears once start with it "spine_...", "head_...". Else insert side shortcut before region "L_...", "R_..." ("L_arm_...", "R_leg_..."). Reasons:

• For regions that appear multiple times (L_arm, R_arm, ...) all related nodes will have unique names, just by adding the side prefix
• Abbrevation to save reading time and space. If a name is too long for a Maya UI element (ChannelBox, graph editor, ...) the name usually (always?) gets cut of at the right side. So having a short prefix delays that. Opposed to using the more descriptive, but longer versions "Left_"/"Right_" or "Lf_"/"Rt_".
• This is a "special rule" (anti readability and simplicity), but it is such a simple one and used so frequently that is hard to use wrong or forget.

Middle = Hierarchy ("...1_upper...", "...2_lower...")

• Start with number, counting in the cranial (spine) / distal (limbs, fingers) / lateral (clavicle) direction, to allow for alphabetic ordering, which can be useful in the paint skin weights tool for example. For most people it is more intuitive to start counting at 1. Opposed to loop variables usually starting at 0 (Python: for x in range(..)).
• Followed by a string description to understand where the element actually is (readability). This string could be standardized, but this post is about a simple naming convention. 
• Going from general to detail is easy to read and helps with isolating regions for string search / filter ("L_hand_2_index*"). 
• All this also helps to have unique transform node names. Which can have the same name, if they are not in the same hierarchy level. Opposed to "pure" DG (dependency graph) nodes (multiplyDivide, skinCluster,...).

Examples:
L_arm_1_upper_... > L_arm_2_lower_... > L_arm_3_wrist_...
L_hand_1_thumb_1_metacarpal_... > ...
L_hand_2_index_1_metacarpal_... > L_hand_2_index_2_phalanxProximal_... > L_hand_2_index_3_phalanxIntermediate_... > L_hand_2_index_4_phalanxDistal_...

Suffix = Nodetype ("..._multiplyDivide", "..._locator")

The nodetype is usually the suffix. Theoretical that should not be necessary, since command searching allows for a type filter (pm.ls('L_arm*', type='joint')). But when manually working in a scene it helps to read graphs / history and it also helps at having unique names.

Usually it is also shortened to 2-3 letters, which I used to do as well (joint = jn/jnt, blendColors = bc, multiplyDivide = md). But after changing my "rules" over the years and using different ones at companies I suddenly wondered what the purpose of these abbrevations even is. Since they always introduce special rules, exceptions and may not even be readable from an outsider.

So my conclusion was to just use the full default Maya node names / types as suffix:
"..._blendColors", "..._multiplyDivide".
In the beginning, when more nodes were created manually, it might have been more convenient to only type a few letters as suffix. But by now most are generated with scripts anyway.  And even when working manually and following this rule the default Maya behavior will generate the suffix by default (minus the 1 at the end).
But more importantly this rule creates unique, easy to learn, obvious suffixes for almost all nodes. There are a few exceptions, but even their solution are partly given from Maya. So they always make sense to Maya users.

Exceptions - from Maya:

• Default transforms will get different names in Maya, depending on how they got created: null1 (empty group), group1 (group for transforms), transform1 (actual node name). Most people call default transforms (no shape / special function) groups, so I stick with group as well. To prevent hard to read suffixes when using stacked groups ("..._group_group_group") I like to use descriptive names ("..._null_group", "..._sdk_group", "..._space_group").
• Transforms with shapes get names from the shape nodeTypes (locator1, annotation1, ...). So Maya already gave an answer how to name those transforms. Shapes themselves will get the Shape suffix.
• Transform Handles (deformer handles) get named: "nodetypeXHandle" in Maya. So I also use this convention, except for the number in between, so it's only "deformertypeHandle". Example: L_cheek_clusterHandle (cluster itself: L_cheek_cluster)
• ... (probably more)

Exceptions - from user:

• Animation transforms: Usually transforms are the only nodes animators are exposed to. That's why they often get named differently. For this convention I prefer "_control" over "_nurbsCurve".
• ... (probably more)

Code

# python examples
import pymel.core as pm
my_module = 'L_arm_'
my_joint = pm.createNode('joint')

# manual
my_joint.rename('{0}1_upper_{1}'.format(my_module, my_joint.type()))

# if you have a function to detect the suffix:
my_auto_suffix_rename(my_joint, name='{0}1_upper'.format(my_module))

# if you are in a rig module instance that detects the module:
self.my_auto_rename(my_joint, name='1_upper')

Notes: 

• Maybe lowered prefix letter (Pro: Consistency, closer to PEP8 Python recommended variable names [lower_case_with_underscores]. Con: Lower L looks like capital i)
• Maybe have a prefix for all areas for consistency ("C_" = center, ...)