Пустой случай по умолчанию в частичном переключатель против, если предложение

Question

Предположим, что у вас есть enum типа так:

public enum Type 
{ 
    A, B, C, D, E, F 
} 

Затем вы хотите сделать что-то в зависимости от некоторых значений, так что вы создать переключатель предложение:

switch (type) 
{ 
    case Type.A: // Do something 
     break; 
    case Type.B: // Do something 
     break; 
    case Type.C: // Do something 
     break; 
} 

Это компилируется и работает нормально, но затем Sonarqube 5.2 (с правилами по умолчанию для C#) проверяет код и жалуется на switch, не имеющий случая по умолчанию (он квалифицирует его как серьезную проблему). Таким образом, вы измените код на это:

switch (type) 
{ 
    case Type.A: // Do something 
     break; 
    case Type.B: // Do something 
     break; 
    case Type.C: // Do something 
     break; 
    default: // Do nothing 
     break; 
} 

Но тогда это SharpDevelop, кто жалуется, поседение дела по умолчанию, и говорят вам, что код не должен быть там, так как он не делает ничего.

Таким образом, вы в конечном итоге изменить код на if предложение:

if (type == Type.A) // Do something 
else if (type == Type.B) // Do something 
else if (type == Type.C) // Do something 

С помощью этого кода, ни SonarQube, ни SharpDevelop жалуются на всех. Ну, SharpDevelop любезно предлагает, чтобы if можно было преобразовать в switch.

Итак, какой путь лучше? Должен ли я добавить случай по умолчанию к switch и игнорировать SharpDevelop? Должен ли я игнорировать проблему в SonarQube? Или я должен просто пойти на предложение if? Есть ли другой способ сделать это более правильно?

Answer 1

Ну, на мой взгляд, у вас всегда должен быть случай по умолчанию. Я делаю исключение в случае по умолчанию, потому что это указывает на то, что я забыл код (как правило, добавленное значение перечисления, например) и четко показывает, где ошибка.

Что вы делаете, конечно, зависит от того, что подразумевается в вашем приложении по умолчанию. Есть ли действительно состояние, где «ничего не делать» - это хороший путь через код? Это обычно указывает на дефект или хрупкий код, который должен привести к рефакторингу. То же самое касается if блоков без else, которые вы предложили для работы. На самом деле, я удивлен, что сонарква не жалуется на это.