As far as the casing, it really makes no difference, but as others have said I think it is important to choose a naming convention and then stick with it. For example, we allow spaces in variable/data item names because it functionally makes no difference in Blue Prism since you always have to put [] around the data item references in expressions.
I also don't see any real point in putting an indication of the datatype within the name, though I often do this if I have the same data on a page/action being casted multiple times and transferred from one datatype to another. At that point I might do something like you did such as txtData, numData, etc.
As B Pat said, Actions should be named as Verb-Object, but this is common to any programming language or technology that involves making methods or functions. I think PowerShell naming conventions for functions is the best example of this.
One area that everyone struggles with in deciding naming conventions in Blue Prism environments is how to name processes and objects. Again here, I think it's best to name processes also with the Verb-Object convention ('Upload Statements' or 'Cancel Orders'), and then Objects should be named as a noun ('Credentials' or 'Collections') to refer to the topic or functionality around which actions are created. In addition to that, I think it's best to give Processes prefixes, based on what you need. I typically do not name them with a prefix of the business unit, but I have seen this done in the past. Normally, I put the overall name of the automation first, followed by the Verb-Object ('Order Reconciliation - Cancel Orders' or 'Order Reconciliation - Review Orders'). One thing to keep in mind is that the Blue Prism UI is not going to dynamically resize based on the size of your process/object names so the shorter the name the better.
C# code: Note that if you make an input parameter for a code stage with a space in the variable name, it will get an underscore when used in the code ('First Name' will become 'First_Name'). So, I often don't put spaces in input parameters for code stages just for consistency ('firstName' or 'FirstName' won't be changed when going into the code stage).
I also think it's a good idea to pick a naming convention for Calendars because, last I checked anyway, you can't edit the name of calendars. Hmm...hopefully that will change or has already changed. Something like: Define the Working Week and then define the holidays ('Working Week M-F - US Holidays' or 'Working Week 7 days - No Holidays'). Another fair idea is to simply not reuse calendars but instead to make a new calendar for every automation that needs one so that adjustments to the calendars does not inadvertently affect multiple business units' automations.
Another really important one is to decide a naming convention for Environment Variables. Include spaces or don't include spaces, it doesn't matter as long as it's consistent. But the MOST important thing about this is to have prefixes so that the variables are listed next to each other alphabetically. And whatever you do, don't let anyone create a Proof of Concept (POC) automation without using this naming convention. Otherwise, you may find yourself years down the road with these random environment variables that you're too afraid to delete, but they annoy you every day because they break up the alphabetically ordered list of env vars that do follow the naming convention. I'm not bitter.
😃Another note about naming actions and input parameters. You can always add new actions or add new input parameters without breaking references, but you cannot change the action names or change the spelling of input parameters without breaking the 'contract' of ensuring that action calls/references will always work. Blue Prism did this with the Date and Time Manipulation VBO when someone at BP randomly decided to fix the capitalization of one of the actions 'Local to UTC' or 'UTC to Local'. They changed a lowercase 'l' to a capital 'L'. This is the kind of contract breaking thing you want to avoid. So, naming conventions are important, but maintaining support for calls to actions is MORE important than fixing typos or spelling errors in the names of actions and inputs.
Ok, I think I'm done writing this novel. I should send it off the publisher now.
😉------------------------------
Dave Morris
3Ci @ Southern Company
Atlanta, GA
------------------------------
Dave Morris, 3Ci at Southern Company
