Should I have a method name longer than its statement?

Question

According to General Naming Conventions of .NET framework:

X DO NOT use abbreviations or contractions as part of identifier names.

For example, use GetWindow rather than GetWin.

X DO NOT use any acronyms that are not widely accepted, and even if they are, only when necessary.

I've once consider GetName can be used for my method, but I believe it's not so sematically meaningful.

In order not to deviate too far from the naming convention, I've tried to figure out widely accepted acronyms, but I just run out of ideas for the following method:

String GetExplicitInterfaceMemberImplementationName(MemberInfo info) {
       return info.DeclaringType.Name+"."+info.Name; 
}

For this case, it is, in fact, not really longer than the statement, but just the identical length; and Type.Delimiter should be used rather than ".". However, the naming problems so often bothers me.

So, what method name should I declare? And for the long-term solutions, what can I do?

For an additional question, is there an API out of the box does the same thing?

---

Edit 1:

Stop and think, such a good suggestion for me.

For the purpose of its statement, also for semantic and not breaking the naming conventions, I got an idea from [AddAttributeStoreCommand.TypeQualifiedName Property]; so I now declare it as:

public static String GetTypeQualifiedName(this MemberInfo info) {
    return info.DeclaringType.Name+"."+info.Name;
}

Yet, a long-term solution hasn't come up ..

---

Edit 2:

I'm not sure whether it's a good practice to name like this ..

public static String GetTypeDotItsName(this MemberInfo info) {
    return info.DeclaringType.Name+"."+info.Name;
}

Answer 1

1) Put in the information that is needed to make the purpose of the method clear. You can probably halve the length of your example name without any loss of understanding about what it fits.

2) guidelines are guidelines. Don't slavishly follow rules when they become counter productive. If using an abbreviation makes it easier to read and understand the code, use abbreviations. The main thing is to try to limit abbreviations to long names that are commonly used, and use intuitive and commonly used abbreviations for them, so that anyone reading your code can easily work out what they mean. For example, decl is a common abbreviation for declaration, and difficult to mistake for anything else.

3) sometimes you can avoid the need to abbreviate by using a synonym.

I think you could probably drop interface and member from your name without losing the meaning. But perhaps the "explicit interface implementation name" is actually the "explicit name" - explicit has a well defined meaning, especially in the context if your class, and you can always add the fully watertight legal definition in your documentation comment. So: "GetExplicitName"

Answer 2

Code Complete 2nd Edition has this to say about method name length:

Make names of routines as long as necessary

Research shows that the optimum average length for a variable name is 9 to 15 characters. Routines tend to be more complicated than variables, and good names for them tend to be longer. Michael Rees of the University of Southampton thinks that an average of 20 to 35 characters is a good nominal length (Rees 1982). An average length of 15 to 20 characters is probably more realistic, but clear names that happened to be longer would be fine.

Note the word average. If the method name is as clear as possible, and it's 50 characters, then whatever. It's fine.

However, the book does mention another thing a few paragraphs up:

If you have routines with side effects, you’ll have many long, silly names, The cure is not to use less-descriptive routine names; the cure is to program so that you cause things to happen directly rather than with side effects.

Of course, side effects aren't the issue here, but you can extend the idea. Ask yourself "Is this long, silly name popping up because I'm doing overly complicated stuff?" If you're sure that you need an ExplicitMemberInterfaceImplementationName, then fine, but it can at least be something to stop and think about.