Suggestion : Super Quick Info fully qualified namespaces for the implemented interfaces

[IneedHelp]

Would it be possible to add an option which allows displaying fully qualified namespaces for the implemented interfaces as such:

[wmjordan]

Personally I don't think the namespace before the interface name can be very helpful. What a programmer want to know about an interface is its purpose, thus the name is enough, most of the time. Hence Codist hides namespace names from view as much as possible.
If you do care about the namespace, you can always hover the mouse cursor onto the interface name and a tooltip will tell you that.

[IneedHelp]

While engrossed in the development of an extensive extension like yours, which notably focuses on the prominent presentation of metadata, I comprehend your inclination to shape it according to your own vision, optimizing it for utmost utility. However, given your extensive experience in the field, I believe you are well aware that individuals, particularly developers, often harbor varying preferences when it comes to specific features.

Allow me to present a few compelling justifications for providing the "option" to exhibit interfaces with fully qualified namespaces, elucidating why I personally find it advantageous:

1. displaying fully qualified namespaces, organized alphabetically, facilitates the swift identification of interface clusters and their origins. For instance, it becomes effortless to discern a set of interfaces originating from the System namespace and another group originating from diverse DLL-based namespaces.

2. by including namespaces in the presentation, the functionality we are currently discussing can seamlessly integrate with the proposed enhancement: the ability to swiftly access the source of the displayed namespaces. This is exemplified in Suggestion: Super Quick Info ability to navigate to source of displayed namespaces Suggestion: Super Quick Info ability to navigate to source of displayed namespaces #257

[wmjordan]

Hmm, this suggestion seems be reasonable.

Current implementation displays interfaces declared/implemented by the type first, then inherited ones.

I don't know whether sorting interfaces by namespaces then by type name can help more.

@fitdev
My friend, can you share your comments here?

[wmjordan]

Here's how it looks like when interfaces are sorted by namespace first and fully qualified.

[IneedHelp]

I particularly very much like the sorted by namespace first and fully qualified presentation (and in conjunction with no width limit on Super Quick Info as I dislike having word wrap, I feel like it messes with my ability to quickly perceive the information).

Since this is a more visual tweak than other features, it might be a good idea to have it as a toggle option (as an opt-in by default) so that other users don't have to change settings. Or even better, maybe a toggle implemented straight into the Super Quick Info UI; it could be placed on this line:

so that no space is wasted, since that line always says "Interface:" anyway, even when there's only one interface implemented.

EDIT: another solution would be to use the Shift key modifier to display the new mode (or the old mode), but I still believe that having a toggle button integrated straight into the UI would be better.

[wmjordan]

I still believe that having a toggle button integrated straight into the UI would be better

Years ago I was trying to put some toggle buttons on the Quick Info to allow changing its content after display, but unfortunately the Quick Info disappeared after it was changed.
I will try again to see whether I can find a way.

[IneedHelp]

I will try again to see whether I can find a way.

Even if toggling closes Quick Info, the state should be remembered in subsequent displays of Quick Info, so in a way it's a faster path to change appearance without having to access the Options window.

[fitdev]

My friend, can you share your comments here?

Personally, fully qualifying interfaces is not something I would find useful, but I understand that for some developers it may be useful.

In any case, I hope that it can be an option which users can customize - turn on or off.

As a middle ground, perhaps interfaces can be automatically fully qualified when there is more than one identically named interface coming from different namespaces:

class C : NS1.IFoo, NS2.IFoo {  }

In other words fully qualify to avoid ambiguity. Alternatively, perhaps only the immediate parent namespace may be displayed.

[wmjordan]

@fitdev
Thank you for your opinion.

interfaces can be automatically fully qualified when there is more than one identically named interface coming from different namespaces
perhaps only the immediate parent namespace may be displayed.

I agree.

[IneedHelp]

As some extra reasoning why I suggested this is also because some developers (myself included) employ a top-to-bottom architecture, where dependency increases from top to bottom, and that combined with a proper naming scheme can expose architectural dependencies at a glance, and namespaces play a big role in this organizational strategy. Therefore the grouping or alphabetical display of fully qualified interfaces would present a level of usefulness.

[wmjordan]

Although the code is already ready, what is left is only an option.
I still don't like the fully qualified interface names.

The namespaces add little value to my programming experience. I don't care its namespace at all. I can not even remember any second I have ever wanted to know about it before. @fitdev's example maybe the exception.

But I do care for the functionality of the interface. On the above screenshot of the generic Dictionary, the namespaces take too much space and interfere reading the interface names. It is adding reversal value to programming experience.

[IneedHelp]

I could go on further trying to make a case in favor of fully qualified interface names and without backup from other developers using similar architecture strategies as me, it might seem like I just want this for myself. Finally, it's your decision whether you want to add this implementation or not. Although if you do decide to add it as an option, I'd appreciate it. And I believe that keeping both options won't become a maintenance struggle as they aren't fundamentally different.

Also, I understand that you don't value namespaces in your workflow, but for me (and I assume other programmers too) they are very useful in keeping a well structured solution (especially when using folders to organize project files, and those folders' names are reflected in the namespaces).

Here's a small sample of what I mean

where basically usages are grouped by project and displayed alphabetically, immediately allowing to discover dependency breaking rules, how heavy a type depends on other types. And all this would similarly translate to how useful it would be viewing implemented interfaces preceded by their full namespaces.

[wmjordan]

I am still not convinced.

for me (and I assume other programmers too) they are very useful in keeping a well structured solution (especially when using folders to organize project files, and those folders' names are reflected in the namespaces).

Why do you care for folders or folder names when you see interface names?
When the code is compiled and used elsewhere, there's no more "folders". What you should care for an interface is the implementation contract, defined by that interface.
When you use IEnumerable<T>, do you have a single second care that it comes from System.Collections.Generics, but not System.Collections or System.Collections.ReadOnly? And you don't have a chance to know what folder the code file for IEnumerable<T> is stored in the MS repository until it is open-sourced.

basically usages are grouped by project and displayed alphabetically, immediately allowing to discover dependency breaking rules, how heavy a type depends on other types.

I can not think of a typical usage pattern for the above statement.

[IneedHelp]

Some of the features I suggest on Codist is stuff I see and use frequently from other tools. Whether I am the only one that finds it useful or a lot many that haven't yet discovered Codist, I don't know. Further attempts to create a compelling argument are pointless in this case, and I understand you have your own vision for your tool, and I respect that.

[wmjordan]

The code is in the previous commit.