Comments
Студентов хорошо заставлять пользоваться статическим анализатором еще потому, что далеко не все ошибки проявляются во время тестирования. В молодости при переносе и мелкой модификации программы с VAX/VMS на DOS своей сданной и зачтенной программы я наткнулся на массу ошибок в использовании памяти, которые были бы замечены статическим анализатором.
В те времена я еще думал — «работает, да и ладно». От таких мыслей стоит отучать.
Неициализированные переменные компилятор сам отлавливает, разве нет? Не скажу за все, но Студия точно выдаёт warning C4700: uninitialized local variable 'bla bla bla' used. Может поэтому редко встречается?
И поэтому, думаю, тоже. Однако не панацея. Некоторых (не студентов) какими-то предупреждениями компилятора не оставить. Предупреждения просто не смотрят или отключают.
Зря минусуете. Суровая правда жизни. :)
Некоторые действительно считают предупреждения компилятора недостойными внимания.
Скорее всего этому студенту программирование совсем не интересно. Такие также не задумываются над форматированием кода, названием переменных и функций.
Вся печать, что я не про студентов говорил, а о «программистах». :( Я в силу своего рода деятельности, бывает такого послушаюсь.
Вот, пример, относительно из свежего. Мне один знакомый в icq жаловался после смены работы:

да у меня культурный шок… люди игнорируют предупреждения компилятора. сидел исправлял все это. нашел пару ошибок. пытался убедить своего начальника сектора, что Cstyle cast — бяка и надо пользоваться кастами си++… но пока безуспешно

на этой неделе привел за ручку начальника отдела и 1 из разработчиков и показывал им предупреждения которые выдает cppcheck. потому что если взять 1 разработчика, то он говорит что это не мой код… а в моём все хорошо :)

да, pvs-studio находит ошибки после cppcheck. Но тут бесплатный cppcheck то не приживается. эх…
Более того, нормальные компиляторы уже давно умеют выдавать предупреждения практически по всем описанным в статье нюансам, и это я даже не говорю про компилятор-анализатор clang. Оба компилятора доступны студентам безо всяких унижений.

Но проще сказать чем сделать — кто из студентов смотрит на предупреждения компилятора, сдавая зачёт в последний день? И кто сказал, что такие студенты начнут пользоваться анализаторами, стыдливо показывая пустую зачётку?:)
У студентов самая большая проблема по-началу — неумение читать сообщения об ошибках. Даже однозначные «no such variable 'x' in scope» вводят некоторых в ступор.
А ещё студенты любят игнорировать warning'и. Сам этим грешил, каюсь… Посоветовал бы студентам включать флаги
-Wall -Werror

Много чему научат…
У нас был преподаватель (ПЯВУ, язык Си), который не принимал лабораторные без -Wall -Werror -pedantic =) если бы ещё каждый сам писал лабораторные — больше народу соображало бы.
Имхо, студенты должны учиться на своих ошибках, а не халявить с анализаторами кода )
Чтобы можно было учиться на ошибках, кто-то должен на эти ошибки указать. Предположим, студенты используют memset(), чтобы перезаписать массив, в котором хранился ключ шифрования, а компилятор удалил вызов memset(), потому что смог определить, что этот вызов в именно этом месте, согласно Стандарту, не влияет на так называемое «наблюдаемое поведение» (описано подробно тут). Как вы думаете, насколько реально, что студенты это найдут?
Если надо готовить не системных программистов, а прикладников, то С++ уже не вариант и проблем таких не будет.
Но даже в упомянутом случае, если студент от безысходности полезет в дизассемблер — это ему только в плюс пойдет. Хотя как вариант в случае безысходности, можно и к анализатору прибегнуть.
Обходя аккуратно разложенные грабли, мы теряем ценный опыт.
Чтобы он полез в дизассемблер, он должен сначала пронаблюдать, что «что-то не так», и взяться это исследовать. Например, он заметит, что в конец сохраняемого программой файла каждый раз дописывается один и тот же блок случайных на вид данных. Если программа записывает, например, JPEG, в котором после кодированного изображения можно безболезненно записывать что угодно, он может и полениться выяснять, в чем именно проблема.
Если все работает, он и сообщения анализатора проверять не будет. А с анализатором и в дизассемблер не полезет — зачем — починил — все ОК, ради чего вдаваться в подробности?
Понятное дело — можно пользоваться анализаторами и отдельно курс про ошибки пройти с детальным рассмотрением. Но теория обычно плохо усваивается.
Анализатор как раз целенаправленно ищет типовые дефекты, делает это довольно быстро, не устает, обычно выдает хорошо продуманные предупреждения. Запустить анализатор хотя бы из любопытства (кто-то рассказал, что это такая крутая штука, которая в его программе воооот такую ошибку «на ровном месте» нашла, надо попробовать) и увидеть крайне неожиданное сообщение о возможном удалении вызова memset(), по-моему, гораздо реальнее, чем пристально рассмотреть машинный код всей программы и найти последствия удаления вызова.
Вроде про студентов с лабами речь? Там ничего невозможного в плане просмотра машинного кода нет, курсовой еще соглашусь. А за 1-20 лабораторной работы — ну это должен быть очень крутой студент, чтобы столько наваять, но в таком случае он наверное уже и опытный должен быть…
Можно напороться на неопределенное (или определенное :-)) поведение, а в asm увидеть, что написанный тобою код оказался вообще вырезан. Такие случаи и у студентов бывают. Но мне к сожалению не приходилось видеть, чтобы начинающие программисты смотрели в ассемблерный код, чтобы понять, что работает не так.
Я не говорил «невозможно». Очень терпеливый студент™, возможно, и найдет, но статический анализатор, скорее всего, сделает это быстрее и надежнее.
Разумеется статический анализатор сделает быстрее и надежнее, только экспириенс будет мелкий )
UFO landed and left these words here
> Express-версии Visual Studio не поддерживают модули расширений (plugins)

У них же недавно вышла community версия, которая полностью идентичная pro (http://www.visualstudio.com/products/visual-studio-community-vs)
Дело в том, что тем, кому нужен статический анализатор обладают в среднем следующими признаками:
1. у них маловато опыта
2. они еще не знают о существовании подобных инструментов
Ну что же, PVS-студио статьями на хабре всячески подталкивает их. С выгодой для себя, но это не в упрек будет сказано.
Что лучше — набить себе шишку ища ошибку глазами, получить пистон от учителя за косяки в лабе или использовать инструмент для поиска ошибок — это вопрос даже не спорный, а религиозный. По крайней мере свободу использовать или *не* использовать — не отнять. И это хорошо.
Дело в том, что тем, кому нужен статический анализатор обладают в среднем следующими признаками:

3. Подключаются к разработке уже существующего проекта. Не буду же я перечитывать тысячи строк чужого кода, который никогда ничем не проверялся.
void main()
{
  ....
  //evaulation
  double calc_y[3];
  for (int i = 0; i<3; i++)
  {
    calc_y[i] = F(pop[i][1], pop[i][2], pop[i][3], x[i]);
  }
  ....
}

Здесь явно ругается на pop, а не на calc_y. В статью следовало поместить объявление pop, чтобы было понятно. А на самом деле проблема в том, что предупреждение «V557 Array overrun is possible. The '3' index is pointing beyond array bound» не содержит имени массива, вот вы сами и запутались. Кто-то может подумать, что CppCat ругается на другой массив и решит, что это ложная сработка.
И вот ещё неправильное предупреждение: V612 An unconditional 'return' within a loop. В том примере, который вы показали, на самом деле unconditional 'break', а не 'return'. Вообще правильная формулировка диагностики очень важна :-)
Не то сообщение скопировал. Поправил.
Вот хороший пример, как исправление ошибки на ранних этапах является более дешёвой операцией. Нет бы мне быть чуть внимательнее и сразу сделать правильно. А теперь мне приходится править текст сразу на нескольких сайтах.
Используйте статический анализ, и вы сэкономите массу времени, сил, а иногда и нервов.
Не знаю, на сколько в тему, история из жизни.
Когда еще не учился в инсте, написал девушке курсач. Затем, уже на 1 курсе в том же институте, по счастливой случайности, у старосты оказался тот же вариант. Я подсуетился, дал старосте курсач, и дошло время до объяснения всего этого безобразия. В курсаче была обработка матриц, простейшие действия над оными, и немного работы с указателями. Так вот каково было мое удивление, когда я запросто выкинул 30-40% кода, потому что не мог объяснить, зачем он был нужен.
Все это я к тому — надо знать современные инструменты, с ними гораздо проще разбираться с неизвестными технологиями/языками, и жалко, что студентов к этому не приучают.
Статический анализатор, это отличный code review и code style guide в одном флаконе. Особенно, в случае если нет рядом более опытного старшего товарища. Для студента с амбициями must have, как говорится…
В наше время таких инструментов не было. Товарищей с хорошим опытом разработки С++ тоже. На кувыркался тогда, дай боже. Казалось борешься с ветрянными мельницами. В последствии ушёл с С++ на более высокоуровневые языки.
UFO landed and left these words here
Only those users with full accounts are able to leave comments. Log in, please.