How do you name your Dynamo script files for description to users?

I am creating company standards for Dynamo including the dyn file names.
The name should be easy to follow so that any user can understand what they are used for without guessing.
Does anyone have any standards or tips about this approach or what works best for your group?

One user at my company created this system for naming Grasshopper files which is a starting point. I think it has merit but could use some trimming

(Authoring Platform)-(Category Combination)-(Description #1)-(Description #2)-(Revit Version)-(Dynamo Version)-(Script Version#)

Example Grasshopper File Name:
GH - GE - Exterior Louvers - Solar Radiation Reduction -

Breakdown of the name sections:

Authoring Platforms:
Grasshopper = GH
Dynamo = Dyn

Geometric = G
Data = D
Environmental = E
Production = P

Description #1 Examples:

  • Functional Description

Description #2 Example:

  • Additional Description
  • Primary plugin used

There’s also a part for script version which is at the end as ’’ but that’s less important for the user than the developer.

Imagine you have 200+ scripts, i would divide them up by user capabilities and make sure the description matches their level of use.
Encoding lures people into experimenting with scripts that could f*ck things up.


There would be two different kinds of script categories for users. One for novices that can run Dynamo player scripts only and described appropriately as such.
And the other set for users who have training to understand how Dynamo works and can navigate to the file they need. The encoded scripts would be easier for them to follow.

I would leave a disclaimer for these scripts that they may not always work perfectly and provide resources on looking up errors.

The main question is if there is a good description naming so the file names aren’t too long and can show up in a given file browser or dynamo player without cutting off the essentials.

Beware of making too cryptic names. KISS = Keep It Simple S??id.

I support @Marcel_Rijsmus comment, that’s a good practice. I have typically the following Daily, Project, Performance, Compliance, Design. This covers the small defns that cover daily tasks and can be run many times by users, in Player or not. Projects covers the Setup, Development and preparation for sharing. Performance covers all the checks, warnings, validations of data. Compliance does the checking, parameters and settings, geometry checks, clearances etc. Design, is all the computational stuff (empty at this time).
I did like an idea the other day of using #util, #settings which allows the browser in Dynamo to search groups quick.


My rules for evaluating any kind of naming, numbering, or cataloging system.

  1. If I need to eat a box of cereal to get the decoder ring to I know what it does, the system should be reconsidered.

  2. If both the summer intern from the local high school and that senior principal who hasn’t booted up his computer since last May would need a primer or supervision, the system should be reconsidered.

  3. If the system has redundant information built into it (ie: marking something as Grasshopper or Dynamo when the file extension or containing folder will do the same), the system should be reconsidered.

  4. If the system doesn’t allow for searching via ctrl+f, the system should be reconsidered.

  5. If the name will wind up exceeding 50 characters, the system should be reconsidered.

That said, reconsideration doesn’t mean ‘delete it’, but it may mean that you want to make a strong business case for that aspect of the system.

I’ll use the DYN and GH prefixes you proposed as an example here. If keeping the GH / DY can’t just type W on their keyboard to get to or at least near the graphs for windows in either platform as the user is trying to find graphs which resize windows for maximum solar performance. Instead they have to mouse wheel which may be fine if you have 50 graphs, but what if you have 5000? Let’s say this will cost users an extra 5 seconds each time they have to find a graph. In this case the cost your business case has to overcome is at least 5*(expected daily uses of anything in the system) * (expected life of the system). I’ll assume 20 uses a day, and a 5 year system life span. Does the prefix save someone 1.3 days, (perhaps in being able to confirm you have a DYN and a GH for every graph)? If yes, show someone the math to double check it and keep it. If not I would drop it and focus on finding aspects which at a minimum break even (good descriptions, and names which help users find stuff go a long way).

Remember you can always use meta data of the files, and ‘non user facing content’ to help sort stuff on the development side and in the long term.


Based on the comments here I have considered a consolidated approach.
Category, Description, Player Script notification.
The Dynamo Type is removed because it is in the file name and the description should be only one or two words.

The only part that needs to be learned is the abbreviations but that won’t be a long list. I’m divided between making project modifications like Life Safety their own category or just make it part of ‘Design Edit / DE’ or something like that.

It is still looking easier to read than the first pass. Any comments about this system would help refine it further.

  • Dynamo naming logic:
  • Category
    • Project Setup
      • PS
    • Health Check
      • HC
    • Compliance Standards
      • CS
    • Life Safety
      • LS
  • Description
  • Player Script Append
    • PLY


Non-Player Script:

Player Script:

1 Like

I agree with what @JacobSmall has said, and if you really do feel you need more description put this within the script.

And possibly use the content library solution i have created to be able to read information from a script without opening it.

1 Like