With Visual Studio 2010 (possibly 2008 as well) I am noticing behavior where Intellisense will suggest the fully qualified namespace for enums.
For example, I can write code like this:
element.HorizontalAlignment = HorizontalAlignment.Right;
element.VerticalAlignment = VerticalAlignment.Bottom;
But when I try to write it, it suggests I write it like this:
element.HorizontalAlignment = System.Windows.HorizontalAlignment.Right;
element.VerticalAlignment = System.Windows.VerticalAlignment.Bottom;
This unnecessary extra code can really add up and makes it less readable, and I have to basically fight with Intellisense to avoid it.
Is there I reason for this? Can I just turn it off? I assume the reason is that the name of the enum is the same as the name of the property. But that’s really not a good reason.
EDIT:
Here’s another example that demonstrates why fully qualified naming is not necessary.
using SomeOtherNamespace;
namespace SomeNamespace
{
public class Class1
{
public Class2 Class2 { get; set; }
public Class1()
{
// These all compile fine and none require fully qualified naming. The usage is context specific.
// Intellisense lists static and instance members and you choose what you wanted from the list.
Class2 = Class2.Default;
Class2.Name = "Name";
Class2.Name = Class2.Default.Name;
Class2 = Class2;
}
}
}
namespace SomeOtherNamespace
{
public class Class2
{
public static Class2 Default { get; set; }
// public static Class2 Class2; (This throws an error as it would create ambiguity and require fully qualified names.)
// public static string Name { get; set; } (This also throws an error because it would create ambiguity and require fully qualified names.
public string Name { get; set; }
}
}
This indeed seems to be the same name for property & the type.
Here is the smallest reproducible example that mimics things (could be smaller but this reveals more)…
Both
MyEnumandTestEnumproperties (targettingTestEnumenum) offer ‘fully qualified’ names (other has different name than its property type but the type matches other property’s name, so both are ‘tainted’) – while SndTestEnum has different naming (for type, property) and works fine in either case.…funny thing is that even if you remove
namespace MyCallerNSand put all under the ‘long namespace’ – it’d still addAndSomeMore.in front.There is not solution as I see it (short of Re# and 3rd party tools),
this seems to be the IntelliSense not being as smart as the compiler case, as @Rick suggested.
Or rather – compiler takes its time to resolve things (with all the info at hands), while IntelliSense does not have that ‘depth’ and insight into things (I’m guessing, simplifying really – we need @Eric on this:) and makes fast/easiest choices sort of.
Actually, on my previous thought,
it’s more about the ‘job’ that each perform – and IntelliSense (as a completion ‘service’) has to present you with all the choices (both the property name and the type) in the list (I don’t see them both being present, but a guess. And having one choice to cover both would probably be a pain to handle)
So to differentiate it adds the fully qualified names.
And where it ‘fails’ (sort of) is to ‘paste’ the ‘short version’ in the end – which indeed it should I think.