How do you name and sort your scripts (.dyn)?


I’d like to start a discussion about how one should name their actual .dyn-files. I’m working for a company with a somewhat large group of dynamo-users, and we’re trying to a maintain a folder with useful and user-friendly scripts that we’ve made, for anyone to use. We’e now amassed a decent amount of scripts and telling them apart is now getting too complicated.

This is what we’ve been doing so far:

  1. One folder per script, containing the script itself and any support files (instructions, excel templates, families etc.)
  2. The folder & script is named Revit Category_Desciption_Revit verison. E.g. Sheet_Create sheets from excel_RVT19
    (The revit version extension is superfluous in many cases)

The naming convention we’ve followed so far doesn’t cut it anymore. I’m therefore very interetsed in hearing what other people are doing. Do you have any naming standards for your files? How do you structure your script folders to make them more accessible?

Hi @Ralle

The system we have at RBG is as follows…

[job no] - [Script Type] - [Script Name] _ [rev] _RBG.dyn



When scripts are not job specific, the Job no is XXXX.

Our Script Types are

  • UT = utility scripts (a standalone script that doesn’t depend on a bunch of other scripts)

  • WF = workflow scripts (a script that forms part of a workflow and typically is used in conjunction with other scripts)

  • PL = player scripts (although, we don’t really use player much at all)

And for revisions we use A, B and P followed by a numerical sequence that denotes if the script is Alpha, Beta or Production respectively.

We also have strict graph standards - maintained by a custom view extension that manages group colours, ensures that our template is used instead of a blank graph and also deploys the approved scripts to all users globally and in the RBG menu. We track all revision history in the graphs themselves along with other information useful to the user running it.

This system works well for us for the minute, and when it gets to much we can extend it further.

I should also mention we have a comprehensive wiki (with videos) at our workplace and a private GitLab repo where we document too. The wiki is integrated into our dynamo so all the users have access to this.