Что поражает меня при разработке статического анализатора кода
При разработке любого инструмента для программистов, будь то компилятор, статический анализатор или что-то еще естественно используются тестовые проекты, на которых этот инструмент постоянно гоняется. Например, при разработке статического анализатора мы прогоняем его на базе из 70 реальных проектах. Это позволяет быть уверенным, что все в порядке и ничего не отломалось. Кроме того, когда мы разрабатываем новые правила диагностики ошибок, после прогона мы видим, в каких фрагментах кода выявлены новые ошибки. Все логично и очевидно. Так почему же такой заголовок?
Дело в том, что тестовая база проектов – явление довольно устоявшееся у нас. Давно уже написаны статьи про ошибки в eMule, WinMerge, TortoiseSVN... И, казалось бы, что все эти тестовые проекты изучены нами вдоль и поперек. А получается, что нет. Ведь вновь и вновь в коде удается найти новые забавные фрагменты кода.
Вот пример:
void CIrcMain::Disconnect(bool bIsShuttingDown)
{
m_pIrcSocket->Close();
if (m_pIrcSocket != NULL)
delete m_pIrcSocket;
}Код, в общем-то, может даже и работает. В некоторых случаях. Иногда. Когда m_pIrcSocket не NULL. Правда автор не уверен, что m_pIrcSocket всегда будет не NULL и добавил проверку. Но ПОСЛЕ использования. Соответственно, если данный код будет выполнен при m_pIrcSocket, то получим падение, хотя и проверка на NULL есть.
Еще один пример точного такого же плана:
if (!frmExist)
{
frmExist =
tag->Find(ID3FID_SYNCEDLYRICS, ID3FN_DESCRIPTION, desc);
}
if (NULL != tag && NULL != data)
{Здесь сначала разыменовывается переменная tag и лишь затем она проверяется. Вопрос все тот же, если автор уверен, что tag не NULL, то зачем он проверяет, а если не уверен, то проверка должна быть раньше.
Так вот, возвращаясь к вопросу, вынесенному в заголовок заметки. Что поражает меня – так это то, что хотя мы много ошибок в коде УЖЕ нашли в наших тестовых проектах, мы все продолжаем и продолжаем находить новые ошибки. С одной стороны это логично, ведь анализатор развивается и соответственно находит что-то новое. С другой – поразительно. Ведь, казалось бы, мы уже столько смотрели на эти тестовые проекты и неужели в них можно найти что-то новое. Оказывается можно.
Ну и совсем уж очевидный вывод – оказывается анализатором кода смело можно прогонять свой проект еще, и еще, и еще. Ведь помимо ошибок в новом коде, который только недавно был написан, можно найти и новые ошибки в старом коде.