Attribute/Base Class Naming

[chris.bahns]

Hello All,
I am fairly new to creating custom attributes, and want to get a
better feel for how they should be named.

We have a class hierarchy, with a base class called "SequenceCommand".
This class has a couple static functions and an embedded class, all of
which are referenced in code like "SequenceCommand.Create()" or
"SequenceCommand.ArgumentDef". There is also a fairly rich hierarchy
of classes under it (maybe 10-15 intermediate classes and about 30
concrete/instantiable classes).

We recently created a custom attribute, which we would apply to the
concrete classes in the hierarchy that we intend to "use" (allowing
them to be used in reflection). This makes our reflection code, which
finds usable classes by name, quite a bit cleaner. Classes without
this attribute are not used, even if they are otherwise capable of
being instantiated, etc.

We want to call this custom attribute class
"SequenceCommandAttribute". The fact that you are applying this
attribute to a class implies that it is "usable", "instantiable", or
"executable", so I think it is slightly redundant to include these
terms in the name of the attribute class.

This approach leads to code like...

[SequenceCommand("MY_COMMAND")]
public class MySequenceCommand : SequenceCommand
{
// implementation

}

There is no conflict here, but it just looks odd that you see
"SequenceCommand" in two places -- one of which is actually referring
to the SequenceCommandAttribute class.

Question: Is this bad practice?
I have found two similar classes in .NET:
System.Runtime.Remoting.Activation.UrlAttribute and
System.SecurityPolicy.Url. These are in two different namespaces, but
perhaps, with the right combination of "using" statements, they could
lead to the same syntax I am describing.

Two alternatives:
1. Change the base class to "SequenceCommandBase"
I don't like this because of the references to the embedded class
"ArgumentDef" and the static functions. ("SequenceCommandBase" just
does not feel right in those cases)

2. Change the attribute class to "ExecutableSequenceCommandAttribute"
I don't like this because it is a little bit verbose, and the
attribute will be applied in many places.

Is there an official position on this sort of thing?
TIA for your help!
- Chris

 

[Nicholas Paldino [.NET/C# MVP]]

Chris,

I wouldn't say that it is bad practice, but perhaps you can rename the
SequenceCommand to be more reflective of what you are trying to do. For
example, "MY_COMMAND" is some sort of key, or command text, right? In that
case, you can be more specific with the attribute name, naming it something
like "SequenceCommandText" or "SequenceCommandKey". Of course, this
attribute serves double-duty, in that your framework can only use the class
if that attribute is on it.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hello All,
I am fairly new to creating custom attributes, and want to get a
better feel for how they should be named.

We have a class hierarchy, with a base class called "SequenceCommand".
This class has a couple static functions and an embedded class, all of
which are referenced in code like "SequenceCommand.Create()" or
"SequenceCommand.ArgumentDef". There is also a fairly rich hierarchy
of classes under it (maybe 10-15 intermediate classes and about 30
concrete/instantiable classes).

We recently created a custom attribute, which we would apply to the
concrete classes in the hierarchy that we intend to "use" (allowing
them to be used in reflection). This makes our reflection code, which
finds usable classes by name, quite a bit cleaner. Classes without
this attribute are not used, even if they are otherwise capable of
being instantiated, etc.

We want to call this custom attribute class
"SequenceCommandAttribute". The fact that you are applying this
attribute to a class implies that it is "usable", "instantiable", or
"executable", so I think it is slightly redundant to include these
terms in the name of the attribute class.

This approach leads to code like...

[SequenceCommand("MY_COMMAND")]
public class MySequenceCommand : SequenceCommand
{
// implementation

}

There is no conflict here, but it just looks odd that you see
"SequenceCommand" in two places -- one of which is actually referring
to the SequenceCommandAttribute class.

Question: Is this bad practice?
I have found two similar classes in .NET:
System.Runtime.Remoting.Activation.UrlAttribute and
System.SecurityPolicy.Url. These are in two different namespaces, but
perhaps, with the right combination of "using" statements, they could
lead to the same syntax I am describing.

Two alternatives:
1. Change the base class to "SequenceCommandBase"
I don't like this because of the references to the embedded class
"ArgumentDef" and the static functions. ("SequenceCommandBase" just
does not feel right in those cases)

2. Change the attribute class to "ExecutableSequenceCommandAttribute"
I don't like this because it is a little bit verbose, and the
attribute will be applied in many places.

Is there an official position on this sort of thing?
TIA for your help!
- Chris

 

[chris.bahns]

Chris,

I wouldn't say that it is bad practice, but perhaps you can rename the
SequenceCommand to be more reflective of what you are trying to do. For
example, "MY_COMMAND" is some sort of key, or command text, right? In that
case, you can be more specific with the attribute name, naming it something
like "SequenceCommandText" or "SequenceCommandKey". Of course, this
attribute serves double-duty, in that your framework can only use the class
if that attribute is on it.

Nicholas,
The application of the attribute is primarily meant to indicate a
"usable" or "executable" command. It is not just represent the name of
the command (the name is just a required argument to the attribute
constructor). This attribute may have other properties as well, other
than the name, which control how the command is used by the framework.
A class without this attribute is simply not used by the framework at
all, even if it derives from the 'SequenceCommand' class.

Thanks for the help. I think I'll leave it the way it is for now.
- Chris