david_r wrote:
You'll find some topics covered in the (old) training manual, but it's by no means an official guide. I think most experienced users end up with some preferences and/or pet peeves, but tastes and preferences differ.
To answer your first three specifically, based on my own preferences:
- Parameters, public or private, are always UPPER case with underscores in my workspaces. That makes them easy to spot.
- I try to keep it down as much as possible (there used to be a standing joke about more than 3 transformers), but I've got no hard limit. However, I believe that an increased number of transformers merit an increased effort for annotations, bookmarks and a structure that is easy-ish to follow.
- Personally I don't like to nest custom transformers, but for no particular reason other than trying to keep things transparent.
I'm sure there are other users here on the community that can chime in with their own preferences.
To contrast with David,
1. I prefer CamelCase for my parameters. I don't use a style difference between public and private. I do try and keep the names consistent between workspaces. ie OutRoot is one I use often for the Ouput Folder Root Directory.
2. Custom transformers should be based on functionality rather than number of transformers. If you don't need to repeat it (either within the same workspace or different ones), just put them in a bookmark and optionally collapse it. Ie keep the transformers in main, unless you are repeating multiple blocks of them.
3. As far as I am aware there are no performance impacts with nesting custom transformers (CT), but consider the pros and cons of linked vs embedded. If you use a linked CT, changes to it could break your primary CT, whereas going through and updating embedded transformers could be a real pain. I personally use embedded CT when nesting, but in my case most of these CT are "helper functions" for example I have a custom transformer that returns the unit of the feature's coordinate system because knowing whether it's in meters or degrees can affect the workflow.
I would try to avoid nesting custom transformers that access external resources.
4. Bookmarks are a good way to differentiate different sections. I often nest bookmarks, though it is rare that I collapse them. I know some groups colour code their bookmarks (data input, different types of processing , data output) but I don't with the exception of using red to indicate a section that requires user intervention before processing (we have a few cases where the workspace needs to be customized to the data in a way that is too complicated for published parameters)
Use the workspace parameters overview to describe the purpose of the workspace. Give a high level overview of the actual processing, either here, or as an annotation in the main workspace.
When creating custom transformers make sure that interim attributes don't override existing attributes. ex if using an areaCalculator make sure to change to output so that it is not simply _area which could easily already exist on the feature. I start all interim attributes with an !. Many prefer a unique prefix per custom transformer. Likewise make sure to cleanup all interim attributes.
Use junctions to help simply the lines.
I personally don't like to rename transformers, other than to occasionally change the numbering. I'll use an annotation if warranted.
