online store Basic Naming Rules for Scripting
top of page

Basic Naming Rules for Scripting

Naming is an essential part of code readability. It summarizes processes and tags data for a better understanding of what it means. The number 12 doesn’t mean much until it is stored in the variable assets_count. Suddenly this abstract number has a clear association: There are 12 assets here.


Good naming should ALWAYS express the content. It helps to understand the code better, helps future modifications, makes sharing easier and is more professional.


Here are the most basic rules for better naming in your code:


RULE 1: As short as possible but as defined as needed

Unique and expressive names are essential for communication. You can always choose between describing the content (most important) or describing its purpose.


# content: texture path
texture_path = '/server/mike_eyes.exr'

# purpose: texture path for character eyes
char_eyes_tex_path = '/server/mike_eyes.exr'


RULE 2: Use snake_case

Variable, function and module names longer than one word are written in snake_case; separated with an underscore:


asset_name = 'sulley'
joint_node = 'palmL_end'

CamelCase is a valid alternative which is objectively less readable but takes less space. 


selectedAssetName = ''
selected_asset_name = ''


RULE 3: Avoid data types and key words in names

Avoid data types in names instead make it clear by the naming itself. Pluralization can help to distinguish between the single item shader (string) and a sequence of items shaders (list).


character_list = ['mike', 'sulley']  # NO
characters     = ['mike', 'sulley']  # YES with plural

# keyword
def = "/server/project/test.py"


RULE 4: Constants are UPPERCASE, set once and NEVER changed

Constant variables are set once and never changed later which creates trust for their content. They are indicated by UPPERCASE letters. You can find them often at the beginning of your script.


# changing variable
asset_name = 'mike'

# consistent variables
RESOLUTION = [1920, 1080]
PROJECT_PATH = '/server/project'
PI = 3.14159265359


RULE 5: Functions are unique actions

A functions action needs to be expressed in its name. 


read_nodes()          # not a specific enough action
select_read_nodes()   # now we know what it does


RULE 6: Avoid globales and work with locals, arguments and returns

We use global variables all the time but they can become tricky when we start to overwrite them and change the content of a variable. Overwrites need to be defined with the keyword 'global' to have an outside effect else you would create a new local variable in the function. To avoid overwrite confusion simply use arguments and returns for a clear process trail.



More rules

  • Use English words without any special characters.

  • Avoid acronyms and unclear abbreviations

  • Use strong names even for temporary variables instead of x, var, ...


The 6 naming amendments


Good naming exceeds far beyond the "nice-to-have" bridge and expends into "naming is important for great code", "looks professional" and "avoids bigger issues". Scripting is about communication not just with the computer but also with ourselves and others since we are the one who have to understand code for future modifications. A great format and style in form of clear and helpful names is a first step to achieve the clarity we need in the sometimes confusing scripting jungle.


For more check out these masterclasses:


Thanks for reading,

Alex


PS. Subscribe to my Newsletter for more industry insights and scripting topics.



Watch the video explaining the scripting rules in more detail:


bottom of page