Как стать автором
Обновить

Комментарии 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

Почему?
Потому-что есть первая проверка с return.
А если:
public static bool operator ==(ClockState a, ClockState b){
	return false;	
}

public static bool operator !=(ClockState a, ClockState b){
	return false;	
}


Но это конечно же дичь какая то…
И такое мы тоже отлавливаем. :)
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?
«Сейчас WPF практически вытеснило WinForms»
— а это утверждение на чём основано?
Конкретной ссылки дать не смогу. Это общее мое мнение на основе нескольких источников.
А разве WPF уже не устаревшая технология. Там вроде в Майкрософт что-то новое анонсировали
Я не слышал ни о чем новом, хотя WPF ругают за то, что он 10 лет не меняется.
WPF, UWP это всё XAML-based одно и то же по смыслу. Внутренности различаются, но смысл очень близок. Переехать труда не составит. Это даже переездом назвать трудно.
Блажен кто верует…
Раскройте свою мысль. А то как-то больно претенциозно звучит.
Переезд с родственной технологии WP Silverlight на WP XAML, вместо легкой прогулочки обещаной MS, вылился по факту в создание UI с нуля, и дело не только в диалекте XAML, алгоритмы работы самого ядра изменились местами очень сильно и без предупреждения войны. Так же надо учесть, то что PCL сборки содержащие ресурсы нельзя шарить между платформами. В общем у меня фраза «Переехать труда не составит. Это даже переездом назвать трудно.» вызывает нервную усмещку.
А вы не нервничайте. Бывает гораздо, гораздо хуже. Повторюсь, схожести очень и очень много.
Так я не нервничаю, просто в данном случае схожесть только вводит в заблуждение. Хотя надо признать знание XAML от одной технологии очень полезно для освоения другой. К сожалению у МС нет документации по отличиям.
Спасибо за диагностики для DependencyProperty — очень полезная штука. Работают даже для самостоятельно определенного класса DependencyProperty. Правда их названия, начинающиеся с «WPF:», несколько сбивают с толку, т.к. проверяемый код совместим с WPF только в плане наименований. Полагаю, они также работают для Silverlight и для UWP.

А вот диагностика 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; }
Да, в данном случае, откроется диалоговое окно и будет выбран файл пользователя, но зачем тогда нужен параметр, который по факту не используется?


Предполагалось указанный файл выставить в диалог сперва, чтобы файл по умолчанию или директория по умолчанию выбрались. Видимо, «нэ прикатилос»
Зарегистрируйтесь на Хабре, чтобы оставить комментарий