Comments 19
Конечно, бессмысленные проверки встречаются не только в длинных функциях, но и в пределах двух-трех строчек.
private void OnFlipPicTimeline(object sender, EventArgs e)
{
var clock = (Clock) sender;
if (clock.CurrentState == ClockState.Active) // Begun case
{
return;
}
if (clock.CurrentState != ClockState.Active) // Ended case
{
…
}
}
V3022 Expression 'clock.CurrentState != ClockState.Active' is always true. MainWindow.cs 103
Почему?
private void OnFlipPicTimeline(object sender, EventArgs e)
{
var clock = (Clock) sender;
if (clock.CurrentState == ClockState.Active) // Begun case
{
return;
}
if (clock.CurrentState != ClockState.Active) // Ended case
{
…
}
}
V3022 Expression 'clock.CurrentState != ClockState.Active' is always true. MainWindow.cs 103
Почему?
Потому-что есть первая проверка с return.
А если:
Но это конечно же дичь какая то…
public static bool operator ==(ClockState a, ClockState b){
return false;
}
public static bool operator !=(ClockState a, ClockState b){
return false;
}
Но это конечно же дичь какая то…
И такое мы тоже отлавливаем. :)
V3013 It is odd that the body of '==' function is fully equivalent to the body of '!=' function (19, line 25). Program.cs 19
class ClockState
{
public static bool operator ==(ClockState a, ClockState b)
{
bool a1 = false;
return a1;
}
public static bool operator !=(ClockState a, ClockState b)
{
bool a1 = false;
return a1;
}
}
V3013 It is odd that the body of '==' function is fully equivalent to the body of '!=' function (19, line 25). Program.cs 19
Подозреваю, что вопрос несколько сложнее.
И существует даже пример — MsSql, где null ни равен значению ни не равен ему (и даже при сравнении нулла с нуллом).
Тоесть оба оператора в конечном счете могут вернуть false.
public class TestClass
{
private readonly int? value;
public TestClass(int? value)
{
this.value = value;
}
public static bool operator ==(TestClass a, TestClass b)
{
if (a.value == null || b.value == null) return false;
return a.value == b.value;
}
public static bool operator !=(TestClass a, TestClass b)
{
if (a.value == null || b.value == null) return false;
return a.value == b.value;
}
}
[Test]
public void test()
{
TestClass a = new TestClass(null);
TestClass b = new TestClass(1);
TestClass c = new TestClass(1);
Assert.IsTrue(b == c);
Assert.IsFalse(a == c);
Assert.IsFalse(a == b);
Assert.IsFalse(a == a);
}
Что примечательно решарпер игнорирует переопределенность оператора равно и таки утверждает, что последняя строка "Always true", что как показывает практика не так.
Странно, что сравнение null с null равняться fasle — это весьма странное утверждение. Даже с точки зрения SQL выборки, я вполне могу запросить объекты в которых ничего не записано, т.е. там null.
Еще более странно, что в конце обеих функций стоит "return a.value == b.value;", но не будем на этом заострять внимание.
Касаемо "a == a" ругаться вполне себе логично, сама VS даже пишет предупреждение:
Warning CS1718 Comparison made to same variable; did you mean to compare something else?
Еще более странно, что в конце обеих функций стоит "return a.value == b.value;", но не будем на этом заострять внимание.
Касаемо "a == a" ругаться вполне себе логично, сама VS даже пишет предупреждение:
Warning CS1718 Comparison made to same variable; did you mean to compare something else?
«Сейчас WPF практически вытеснило WinForms»
— а это утверждение на чём основано?
— а это утверждение на чём основано?
Конкретной ссылки дать не смогу. Это общее мое мнение на основе нескольких источников.
А разве WPF уже не устаревшая технология. Там вроде в Майкрософт что-то новое анонсировали
Я не слышал ни о чем новом, хотя WPF ругают за то, что он 10 лет не меняется.
WPF, UWP это всё XAML-based одно и то же по смыслу. Внутренности различаются, но смысл очень близок. Переехать труда не составит. Это даже переездом назвать трудно.
Блажен кто верует…
Раскройте свою мысль. А то как-то больно претенциозно звучит.
Переезд с родственной технологии WP Silverlight на WP XAML, вместо легкой прогулочки обещаной MS, вылился по факту в создание UI с нуля, и дело не только в диалекте XAML, алгоритмы работы самого ядра изменились местами очень сильно и без предупреждения войны. Так же надо учесть, то что PCL сборки содержащие ресурсы нельзя шарить между платформами. В общем у меня фраза «Переехать труда не составит. Это даже переездом назвать трудно.» вызывает нервную усмещку.
А вы не нервничайте. Бывает гораздо, гораздо хуже. Повторюсь, схожести очень и очень много.
Спасибо за диагностики для DependencyProperty — очень полезная штука. Работают даже для самостоятельно определенного класса DependencyProperty. Правда их названия, начинающиеся с «WPF:», несколько сбивают с толку, т.к. проверяемый код совместим с WPF только в плане наименований. Полагаю, они также работают для Silverlight и для UWP.
А вот диагностика V3052 могла бы быть немного умнее, реагируя на потерю стека в коде вроде этого:
catch (TargetInvocationException ex) { throw ex.InnerException; }
А вот диагностика V3052 могла бы быть немного умнее, реагируя на потерю стека в коде вроде этого:
catch (TargetInvocationException ex) { throw ex.InnerException; }
Добрый день.
Спасибо вам за комментарий.
К сожалению, на данный момент ни на UWP ни на Silverlight проектах диагностики не отработали. С UWP проблема, скорее всего, состоит в самой диагностике, а именно на какие классы стоит реагировать. В случае WPF и Silverlight это «System.Windows.DependencyObject», а для UPF «Windows.UI.Xaml.DependencyObject». И я конкретно сейчас займусь исправлением данного недостатка диагностики.
С Silverlight проблема более фундаментальна, мы рассмотрим, что можно сделать в течении сегодняшнего для её решения.
Касаемо диагностики V3052.
В данном случае, скорее «это не баг, а фича», но мы еще раз рассмотрим возможность включения срабатывания для подобных конструкций.
catch (TargetInvocationException ex) { throw ex.InnerException; }
Спасибо вам за комментарий.
К сожалению, на данный момент ни на UWP ни на Silverlight проектах диагностики не отработали. С UWP проблема, скорее всего, состоит в самой диагностике, а именно на какие классы стоит реагировать. В случае WPF и Silverlight это «System.Windows.DependencyObject», а для UPF «Windows.UI.Xaml.DependencyObject». И я конкретно сейчас займусь исправлением данного недостатка диагностики.
С Silverlight проблема более фундаментальна, мы рассмотрим, что можно сделать в течении сегодняшнего для её решения.
Касаемо диагностики V3052.
В данном случае, скорее «это не баг, а фича», но мы еще раз рассмотрим возможность включения срабатывания для подобных конструкций.
catch (TargetInvocationException ex) { throw ex.InnerException; }
Да, в данном случае, откроется диалоговое окно и будет выбран файл пользователя, но зачем тогда нужен параметр, который по факту не используется?
Предполагалось указанный файл выставить в диалог сперва, чтобы файл по умолчанию или директория по умолчанию выбрались. Видимо, «нэ прикатилос»
Sign up to leave a comment.
Проверяем исходный код WPF Samples от Microsoft