I've seen several naming standards, and lots of passion around some of them, but most of the ones I've seen are too complex and, IMO, unnecessary. My preference is to keep it simple and readable without trying to embed too much information into the name. Generally, I do something like this:
<prefix>:<descriptive name> <prefix> is something specific to your organization that groups all of your custom workflow together. That way, you keep all of your stuff in one place, and it's very easy to see what's OOB and what's yours. The prefix may also be more than one level, kind of like this: <prefix>:<app>:<descriptive name>. That helps to group related workflow together. For active links, I may even have a third level to indicate the primary form they're with, but not always. For example, I might have something like this: LDS:MIRS:Config:Load Configuration Settings In this case, I have three prefixes (probably the most I would generally have). The first one says it's for our organizations. The second one is the app it's associated with. And the third one is the form it's for (the configuration console). The primary reason for that is that I have a group of workflow related to that form, and this makes it easy to view and work with as a group. That's not strictly necessary, since you can view by or filter by the primary form, etc., but this works well for me. I use two different prefixes for the organization, one for completely custom workflow, and another for modified OOB workflow where we disabled the original and copy it to a new object and modify the copied object the way we need. For example, if I want to modify the following active link HPD:INC:DetailsCurrentIncident_100_OpenDlg I would copy it to LDS_HPD:INC:DetailsCurrentIncident_100_OpenDlg And then disable the original and modify the copy. Using the underscore makes it obvious that it's modified OOB workflow rather than our custom workflow. That's important when you're patching the system, and you need to know what you've modified so you can verify that the patch hasn't broken something, or if you can now undo something you did before, because the patch fixed the issue you were working around. For the last part, I prefer not to try to embed all kinds of things like the execution order, details about what the active link does, etc. They tend to make the names cryptic, and don't add much useful information from what I've seen, especially given the tools we have to work with now. In addition, since names can be quite long, I generally don't abbreviate words much, and often include spaces in the words. The description I use usually is a short description of what the active link accomplishes or what triggers it. I often use the latter for active links attached to buttons, etc. That works well for me, because I generally have the practice of having a single active link on the button that then calls a guide to do the work rather than having a bunch of active links on the button with different execution orders. I've found that works better for me. So that gives me names like this: LDS:MIRS:Console:Check Required Fields LDS:MIRS:Console:Clear Form Or LDS:MIRS:Console:Cancel Button Clicked LDS:MIRS:Console:Assigned Group Entered Occasionally, I will add additional information like sequence numbers of there are two pieces of workflow that are conceptually together. That is, there is conceptually one action being done, but it needs to be done in two steps. Like this: LDS:MIRS:Console:Lookup Assignee_1 LDS:MIRS:Console:Lookup Assignee_2 Looking up and validating the Assignee takes two active links to complete (one to do the look up, and another to verify that it succeeded), and since they're intimately tied together, I give them the same name with a sequence number. I occasionally use underscores in the name when I want to visually separate two parts of a name, like this: LDS:MIRS:Console:Required Field_Assigned Group LDS:MIRS:Console:Required Field_Assignee The first part of the name indicates what it's about (in this case, validating required fields), and the second part after the underscore indicates the field I'm validating. Doing it this way groups the names together in the list and still makes it easy to see the two different parts of the name. You could just as easily use some other separator that stands out to you as well. So, in general, I don't get much more complicated than that, because I don't see much value in many of the complicated naming conventions I've seen, including the ones used by BMC. That said, a large and complicate application or set of applications (e.g., ITSM) could benefit from a rigorous naming standard, but I'm not sure it needs to be as complex as what they've used in the past. Embedding too much information in the name just makes it hard to read, and harder to maintain. For example, if you include the execution order in the name, you'll need to renaming the object if the execution order changes. That has resulted in a large number of active links and filters in the ITSM suite where the name doesn't match how the object is currently defined. Well, that's my philosophy. Others have very different ones, and they may appeal to you more. Good luck. Lyle From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Brittain, Mark Sent: Tuesday, November 24, 2009 10:09 AM To: [email protected] Subject: Naming Standards ** Hi All, I was wondering if there are any good standards for naming filters and active links. On my server there is an amazing mix that appears to be dependant on what worked for the previous Admins. Also is there any need/value to having the name all one word like the last two examples. Really makes it hard to read/find. Here are some examples of what I have. CR-950-Notify Deinstall Closed-Cancelled CR-UpdateAuditLogforAttachmentAdd CR:SM-Company-ChkDefaultEmail-600 (SM=Submit/Modify) Thanks Mark ____________________________________________ Mark Brittain Remedy Developer NaviSite [email protected]<mailto:[email protected]> (315) 453-2912 x5418 (Phone) (315) 317.2897 (Cell) Reduce Cost of IT with Managed Hosting and Application Services from NaviSite. Visit www.NaviSite.com<http://www.NaviSite.com> Today. ________________________________ This e-mail is the property of NaviSite, Inc. It is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential, or otherwise protected from disclosure. Distribution or copying of this e-mail, or the information contained herein, to anyone other than the intended recipient is prohibited. _Platinum Sponsor: [email protected] ARSlist: "Where the Answers Are"_ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are"
