You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Implementation of the rule that check that using directives are ordered alphabetically by namespace do it ignoring the case.
However StyleCop classic was doing it in a case sensitive way.
This difference is not documented into the known changes documentation. There is paragraph about SA1210 but it do not mention any difference about case sensitive ordering.
It also cause Stylecop analyzers to be not compatible with the native "Sort Usings" command of Visual Studio that we can found in the menu "Edit > IntelliSense > Organize Usings" and that perform sort in a case sensitive way.
I also think that doing it in a case insensitive way like now can lead to unpredicted results.
Exemple:
using MyNamespace.Domain;
using Mynamespace.Domain;
using Mynamespace.Domain;
using MyNamespace.Domain;
Those two code extracts are valid with current implementation, both orders are accepted by the rule.
And if you also have other using directives that are not ordered around that ones, and apply the code fix that reorder the using directives, you can't guess which order will be finally applied. I've done some tests and I have achieve to obtain both results at the output of the code fix.
So, outside the fact that having namespaces that differs only by the case in a same project is probably a bad thing, which may be the purpose of another rule, I think that this rule (SA1210) should do its works in a case sensitive way to be perfectly predictive and more compatible with VS.
The text was updated successfully, but these errors were encountered:
❓ What does StyleCop Classic do in the following scenario?
using SomeNamespace;
using anotherNamespace;
The expectation when implementing this rule in a case-insensitive manner was to ensure a was ordered before S in scenarios like the above. It sounds like we need to add a secondary sort order to cover namespaces that differ only by case, and possibly document the known change if the result still doesn't match StyleCop Classic.
I've tried with Stylecop classic and the "sort usings" command of Visual Studio. Both order the results with a before s a bit like if it was case insensitive per portion of namespaces.
Here is the result of a complex exemple:
using anotherNamespace;
using anotherNamespace.Domain;
using AnotherNamespace;
using AnotherNamespace.Domain;
using someNamespace;
using someNamespace.Domain;
using SomeNamespace;
using SomeNamespace.Domain;
In the end the ordering seems to be performed in two passes and per portions. Where a first pass is case insensitive, and a second pass is case sensitive to order portions that differs only by the case.
Implementation of the rule that check that using directives are ordered alphabetically by namespace do it ignoring the case.
However StyleCop classic was doing it in a case sensitive way.
This difference is not documented into the known changes documentation. There is paragraph about SA1210 but it do not mention any difference about case sensitive ordering.
It also cause Stylecop analyzers to be not compatible with the native "Sort Usings" command of Visual Studio that we can found in the menu "Edit > IntelliSense > Organize Usings" and that perform sort in a case sensitive way.
I also think that doing it in a case insensitive way like now can lead to unpredicted results.
Exemple:
Those two code extracts are valid with current implementation, both orders are accepted by the rule.
And if you also have other using directives that are not ordered around that ones, and apply the code fix that reorder the using directives, you can't guess which order will be finally applied. I've done some tests and I have achieve to obtain both results at the output of the code fix.
So, outside the fact that having namespaces that differs only by the case in a same project is probably a bad thing, which may be the purpose of another rule, I think that this rule (SA1210) should do its works in a case sensitive way to be perfectly predictive and more compatible with VS.
The text was updated successfully, but these errors were encountered: