Pull to refresh

Comments 30

    if (ei.ProjectNames.Count == 1)
    {
      ....
    }
    else if (ei.ProjectNames.Count > 1)
    {
      ....
    }
    else if (ei.ProjectNames.Count == 0)
    {
      ....
    }

V3022 Expression 'ei.ProjectNames.Count == 0' is always true. PlogController.cs 277

ei.ProjectNames.Count — беззнаковое целое?
Анализатор знает, что в Count не может содержаться отрицательное значение.
аа… ну-ну ))
*я бы сказал "… ОБЫЧНО не содержатся..."
ProjectNames — это обычный List.

public List<String> ProjectNames = new List<string>();

Как следствие, свойство Count не может содержать отрицательное значение.
А вы можете привести пример с отрицательным количеством элементов в списке?
я апеллирую к ТИПУ возвращаемого значения, а не "физическому смыслу" этого значения
если сделаю я класс-наследник, который может переопределить GetCount (правда, не знаю, можно ли это сделать именно с List в C#; я имею в виду ОБЩИЙ случай), например, и по ошибке или со своим тайным смыслом, будет возвращать значения меньше нуля...

и если PVS анализирует настолько умно, что знает всю логику использования класса и его полей, не полагаясь на ИМЯ значения (как тут говорят) — то снимаю перед ним шляпу

в общем, это больше вопрос к разработчикам PVS: на что опирается данное предупреждение при анализе?
Позволю себе предположить, как оно работает. PVS, вероятно, знает, что Count в классе списка возвращает всегда неотрицатеьные числа. А вот про добавленный кем-то GetCount оно этого не знает, и будет проверять по всем правилам. По мне оно должно работать как-то так. Но это может быть явно задано, для конкретного свойства конкретного класса, а не в смысле "если называется Count, то всегда возвращает неотрицательные, какой бы класс ни был".
я апеллирую к ТИПУ возвращаемого значения, а не «физическому смыслу» этого значения

Проверку по типу совершает компилятор и непонятно, у анализатора работа несколько другая.

например, и по ошибке или со своим тайным смыслом, будет возвращать значения меньше нуля...

Ну тогда вы можете со спокойной совестью проигнорировать это предупреждение.
В остальных же 99,(9)% случаев эта проверка вполне обоснована.
Анализатор знает, что тип Count-а не может принимать отрицательные значения… Само слово "Count" ему ни о чем не говорит...
ну, как раз тип там — System.Int32

ProjectNames — это обычный List.
public List ProjectNames = new List();
Как следствие, свойство Count не может содержать отрицательное значение.

https://msdn.microsoft.com/en-us/library/27b47ht3(v=vs.110).aspx

List.Count Property
public int Count { get; }
Property Value
Type: System.Int32
Int32.MinValue
The value of this constant is -2,147,483,648; that is, hexadecimal 0x80000000.

Хм… Ну, если это обычный список, тогда их анализатор даже умнее, чем я думал и знает, что в списках хоть счетчики и знаковые, но не принимают отрицательные значения, благодаря внутренней логике...
Count имеет тип int, но на практике он никогда не будет меньше нуля. И PVS-Studio знает об этом.
Понятно, крутой у вас анализатор! Я поначалу думал, что это собственный счетчик какой-то, не списочный..
Ну, логично, что счетчик — это беззнаковое целое...
логически — возможно, но по типу — уверен, что Integer (или какой там в C#)

и, очевидно, мы немного с Вами в разных мирах живём ))) в моём мире это лишь "соглашение", но никак не факт )
в общем, я немного занудствую ) профессиональное, простите )
А вы уведомили разработчиков о найденных ошибках?
Стадии адаптации статического анализа в проекте: Отрицание → Агрессия → Торги → Депрессия → Принятие
UFO just landed and posted this here
Спасибо большое.
Извиняюсь. Поправил.
  if (RowsCount > 20000)
    ...
  else if (RowsCount > 100000)
    ...
  else if (RowsCount > 200000)
    ...

Это потому что писавшему не хватило либо мозгов, либо терпения написать условия, которые решают именно ту задачу, которую он решить пытается:

  if (RowsCount > 20000) && (RowsCount <= 100000)
    ...
  else if (RowsCount > 100000)  && (RowsCount <= 200000)
    ...
  else
    ...
Такой вариант плох тем, что появляются два взаимосвязанных числа вместо одного независимого. [для таких случаев хорошо бы константы делать по хорошему[но мы все понимаем, это долго и часто очень лень]]
Плюс ко всему, два данных кода не идентичны. В Вашем "исправленном" примере последний else будет выполняться в том случае, если строк меньше 20000, а мы так не хотим.
На самом деле, вариантов исправления кода много:
Самый очевидный — это поменять строки местами:
int RowsCount = DynamicErrorListControl.Instance.Plog.NumberOfRows;
if (RowsCount > 200000)
DatatableUpdateInterval = 120000; //2min
else if (RowsCount > 100000)
DatatableUpdateInterval = 60000; //1min
else if (RowsCount > 20000)
DatatableUpdateInterval = 30000; //30s

Математический:
DatatableUpdateInterval = RowsCount / 100000.0 * 60000.0
DatatableUpdateInterval = Math.Max(15000, DatatableUpdateInterval); //Нижняя граница
DatatableUpdateInterval = Math.Min(240000, DatatableUpdateInterval);//Верхняя граница
В Вашем «исправленном» примере последний else
Было в лом перепечатывать с нуля, поэтому тупо подредактировал оригинальный код — и, конечно же, нарвался на эффект cape-posty.

И да, есть другие варианты решения этой задачи, причём варианты, в которых не имеется жёстких отсекателей (в частности, тот, который Вы называли «математическая версия») заведомо лучше. Но это не меняет моей основной посылки: комьютер — он как джинн: выполняет всё буквально, поэтому нужно быть очень точным при изъявлении своих желаний.
комьютер — он как джинн: выполняет всё буквально, поэтому нужно быть очень точным при изъявлении своих желаний.

С этим никто не спорит.:) Но когда deadline близко, очень сложно правильно сформулировать свою мысль перед Джином.
А особенно учесть все возможные, все невозможные и часть невероятных сценариев работы программы.
Вот поэтому мы, по мере сил и по мере возможности, пытаемся помочь вам в этом, всеми возможными способами.:)
Но когда deadline близко,
А для тех манагеров, которые не понимают головой, что важнее — дедлайн, или то, что тебе говорят разработчики (и чем это череповато), есть даже специальный комикс:image
PVS-Studio — инструмент полезный но, к сожалению, очень дорогой, доступный далеко не каждой организации. Разработчики этого продукта, скорее всего, ориентируются лишь на достаточно большие компании, специализирующиеся на разработке софта.

В этот круг не попадает огромное количество компаний, специализирующаяся не на разработке софта, а, к примеру, на проектировании (зданий, мостов, и т.п. и т.д.). В таких организациях порой присутствуют пара-тройка программистов, которые пишут код под внутренние нужны компании. Например, наша компания проектирует не безызвестный мост через Керченский пролив (т.е. далеко не самая последняя среди проектных), но даже для нас стоимость этого продукта слишком высока — мне 100% не подпишут счёт на 250 т.р. за годовое использование…

Для прикладных программистов компании покупать приходится не только PVS-Studio, но и очередную подписку MSDN, а так же иные, порой специфичные продукты: Help and Manual, Snagit, Camtasia Studio, Teigha, Resharper, .Net Reflector и т.д. и т.п. Получается очень круглая сумма… Но все они нервно курят по сравнению с ценой на PVS-Studio. Так же приходится учитывать, что теперь и у компании Autodesk аппетиты недетские ( http://www.softprof-it.ru/katalog/autodesk/autodesk-arenda ) — каждый год хотят более чем по 100 тыс. руб с каждой машины за использования обычного, голого AutoCAD (не говоря уж о чём-то более серьёзном), то вообще ситуация становится печальной. Продукты этой компании являются основными инструментами проектировщиков…

А ведь ещё приходится платить и за софт, выполняющий расчёты различных конструкций (стоит миллионы за год использования). В виду этого покупка софта для прикладных программистов в компаниях подобной нашей не является приоритетной и выполняется по остаточному принципу. Если бы годовое использование PVS-Studio стоило хотя бы $1000, то существовала бы достаточно неплохая вероятность того, что её покупку руководство мне бы разрешило, но сумму в 250 тыс. руб за год использования — меня просто не поймут.

На мой взгляд, некоторые фирмы, производящие софт, живут в каком-то своём, оторванном от реалии жизни мире, полагая, что потенциальному покупателю кроме их софта покупать ничего не требуется, в виду чего и ставят цены по четверть миллиона за годовое использование.

PVS-Studio продукт хороший и мне бы очень хотелось пользоваться им, но в виду своей цены, он для меня находится вне зоны доступа. Что-то мне подсказывает, что не только для меня…

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

Тем не менее мы не считаем наши цены высокими, если сравнивать, например, с Coverity. Этот продукт при расчете для крупных команд, обойдётся в 5-10 раз дороже PVS-Studio. Мы заняли среднюю ценовую нишу.

Думаю, дело не в том, что инструмент дорог. Скорее этот тот случай, что инструмент избыточен для маленькой команды. Причин для этого сразу несколько, попробую назвать некоторые:

  • Вы работаете с маленьким проектом где ниже плотность ошибок. Поэтому контроль качества кода ещё не стоит для вас так остро.
  • В маленьких проектах, если начинаются проблемы с качеством, намного проще выправить ситуацию. Достаточно остановиться и заняться обзорами кода, рефакторингом. Т.е. можно что-то сделать в отличии от большого проекта.
  • Маленький проект как правило молод и все люди которые его разрабатывали рядом. Когда проекту 10 лет, его намного сложнее, например, портировать на 64-битную систему. Ибо никто из команды уже не знает какие темные места скрыты в коде. Анализатор приходит на помощь.
  • В больших проектах траты на приобретение статического анализатора совершенно незначительны и незаметны по сравнению с прочими затратами. Для индивидуальных разработчиков и маленьких команд это ощутимо.

По поводу работы с маленькими командами, у нас уже был опыт. Мы предлагали анализатор CppCat за $250. История этого проекта. И этот проект только подтвердил, что статический анализ для маленьких команд действительно не нужен. Или по крайней мере в такой степени, чтобы на этом можно было построить успешный бизнес.
Да, я помню его… Всё же жаль, что CppCat канул в небытие… Я — самоучка и не являюсь профессиональным программистом (к сожалению). помню время, когда впервые случайно увидел информацию о CppCat на хабре (куда, собственно, очень редко заглядываю) и добавил его себе в закладки, с мыслью о том, что как только появится свободное время, то нужно будет его попробовать. Но свободное время поначалу не появлялось, а потом как-то вовсе и забыл о CppCat. Позднее, переходя с NUnit на Typemock Isolator вспомнил о CppCat, полез за ним, но тот был уже пару месяцев как мёртв. Пришлось покупать ReSharper (чего изначально не хотелось).
Sign up to leave a comment.