Flow users should have a defined and documented naming convention for each location. Make your content easy for other users to understand, and flexible by using a consistent naming convention throughout Flow. The following are suggested best practices for naming Flow objects.
- Do not use any special characters ( : / ? # [ec: ] @ !, $ & ’ ( ) * + , ; =) when naming objects. You will reduce potential future issues with upgrades, migrations or integrations by not using special characters.
- Do not use spaces in names (procedure names, project names, variable names, etc.), use either dashes, underscores, or CamelCase. This convention is particularity useful for UNIX systems because in Flow, the log files in the workspace are created with the step names. By not using spaces, you can quickly identify the correct object.
- Use a consistent naming convention across your projects. You simplify the maintenance of your projects when you use a consistent naming convention. For example, you might have two projects that use a different name for the path variable. One project might use “path” for the path variable name, and another project might use “rootPath” for the path variable name. In either case, an additional layer of complexity is added which hinders a user’s understanding and ability to debug either project.
It can be very helpful to create a list of frequently used variables as a reference for anyone who needs to create projects or procedures which makes supporting various projects much easier.
- Use complex variable names to prevent conflicts with Flow intrinsic variables. Do not use simple names such as “project”. During upgrades or migrations intrinsic values can take precedence over the locally defined parameters.
You should also avoid naming variables that end with “Name”. Many intrinsic variables in Flow have Name on the end of the variable. Some examples are jobName, projectName, and procedureName.
- Product versions: All
- OS versions: All