Great suggestions. I add a special character + at the beginning of the
string. This automatically lists the newly created workflow first.
-----Original Message-----
From: Lyle Taylor <[email protected]>
To: [email protected]
Sent: Tue, Nov 24, 2009 1:02 pm
Subject: Re: Naming Standards
**
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]
(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 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.
_Platinum Sponsor: [email protected] ARSlist: "Where the Answers
Are"_
_Platinum Sponsor: [email protected] ARSlist: "Where the Answers
Are"_
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are"
