|
LibrariesRpi.Platform.AppName Think of all the ways I could name completely different versions of a 'Twitter' Library.
I could just call it "Twitter", but then how would you know if it was the desktop version, or the web version? If you were tying to use it in one of your processes, how would you know if it was created using Chrome, IE, Firefox, or Edge? Different people working on this problem could end up with "DesktopTwitter", "Twitter - Chrome", "TwitterWebApp", etc. It would be difficult to reuse anything, and it would definitely be impossible to contribute additional functionality to any of those libraries without potentially creating misleading or inconsistent code. When this happens, trust in existing Libraries drops, making successfully reusable components even less likely--If libraries are difficult to use, developers just rewrite the logic for themselves and the team's entropy increases. Follow this standard, and you wont have to deal with that: 
|
|
ProcessesTargetBusinessUnit.BotName.Role Before I explain any of this, pretend you are on a successful RPA team.
You have dozens of processes spread out over five or six different business units. Some of those processes do reporting, some of them populate Ques, some of them are attended, some of them are not, and so on. Even scrolling through Orchestrator to find processes associated with each other, or associated with a specific business unit, is a chore. But, if all processes written for a business unit start with the name of that business unit, those processes will stay together. The "ProcessName" is also important. You're first impulse might be to name it after what it does.
At a previous client, we had a process with a name like this: BAD: BOA - COH - Court Order Handling Process - Collect Accounts - Bot 1
"BOA" was an abbreviation for that company's name, "COH" was the acronym for the "Court Order Handling" department. "Collect Accounts" was supposed to be a description of what the bot did, and "Bot 1" was the only thing separating that bot from it's closely related counterpart, "Bot 2".
It was horrible. And it only got worse when we realized that other bots also needed to "Gather Accounts" but from different places, or for different teams. Communicating about the status of any of the bots took forever, and, when names sometimes differed by only a single character (i.e Bot 1 vs Bot 2), miscommunication was easy. This bot was so big that if part of it broke, it was difficult to explain where it was broken to different people with varying technical backgrounds and business concerns associated with the process. And, as the process grew, it did more, and the part of its name meant to describe its functionality became less and less accurate. So, you should give your Bots Novel Names Driven by a commonly known theme. (See, "Bot Names" below) The last part of the Process Name, the "Role", makes interactions between RPA Opperations, RPA Development, and RPA Management easier. What part of bumblebee is broken? Bumblebee.Dispatcher. Which part needs to be distributed to five new machines? Bumblebee.Performer. Adding a Role to the end of a Process Name makes it easier to talk about the various processes that make up a single Bot. |
|
Bot NamesBumblebee More than likely, a bot is a combination of several different UiPath Processes--but that doesn't matter to anyone outside your team. This is the most general way to refer to the sum of all the parts in a full automation solution.
Proper nouns are easy to remember. Pop culture references are great because, as soon as you've told people what the bot's name is, they remember it forever. They feel comfortable asking about it in passing, and therefore have an easier time getting involved with the work. My most recent process was named after a character from the Transformers Movies--"Bumblebee." Our team used imagery from the Transformers Movie or TV Show in our status reports. |
|
|
Arguments
in_SomeArgumentGoingIn Put the direction of the Argument before the name. UiPath Recommends doing this, and it makes your logs easier to read.
|
|
|
Variables
nameOfVariable - No meainingless names, like "x" or "Number"
- No default names like "variable1" - Avoid abbreviations; they make your code impossible to search for anyone who doesn't know what abbreviations you used. - Be as specific as possible: long names are better than vague names. - Start with a lowercase letter. - In general, just follow Microsoft's Naming Guide |
|
|
WorkflowsDoExactlyOneSpecificThing Sequences, State Machines, Flowcharts.
Use a capitalized, Present Tense Verb Phrase, preferably with a direct object.
UiPath follows this standard: 
Good naming can protect you from poor design. If a workflow is too complicated to accurately describe with a simple phrase, you should probably break it into smaller parts.
Organize your RPI's so that naming is easier
Your RPI folder structure should imitate the navigational structure of it's target application:
If you do this, someone who understands how to use an App will also know how to use whatever RPI is built around it.
Private vs Public Workflows
Public Workflows become Activities available to Processes. So, they should be named after a goal an end user would have while using the app. "Tweet What's Up" would make a great Activity name.
Private Workflows are only available within their their own library or process. They are typically more technical. These should be marked as "Private" to hide them from whatever Process uses them, preventing confusion and clutter. Some workflows are extremely technical and would never be used outside the RPI itself.
For our Twitter RPI, "Read First Notification" is a fine name for a public workflow action. "Wait Until Notification Page Fully Loads" however, sounds much more like it should be hidden from the Process. |
|
|
DisplayName - Sequence, Assign, If, For Each, etc.
Commonly used built in activities should never be left with their default name. Because, if you don't change the name, your Outline goes from being really useful to completely useless:
|