Типичные комментарии к коду на С++, выставляемому на ревью

Июнь 7th, 2011 by rius

При разработке ПО командой программистов как правило используется одна из систем контроля версий. Для того, чтобы внести свои изменения в репозиторий, члену команды нужно получить одобрение нескольких авторитетных разработчиков. Они могут подсказать более эффективный вариант или подсказать неочевидные побочные эффекты вашего варианта кода. Часто к первой ревизии изменений разработчик получает комментарии, которые он должен учесть при выставлении следующей ревизии на ревью.

Опустим совсем уж нелепые ошибки и неточности (магические числа и пр) в коде. Про подобные вещи можно прочитать, например, в книге «Совершенный код» Макконнелла. А вот специфичные для программ написанных на C++ рассмотрим подробно.

При выделении памяти лучше избегать malloc/free. Для того, чтобы сделать код с ними безопасным с точки зрения исключений, придется постараться. Переписывать старые библиотеки по этой причине не стоит, а вот в своем собственном коде лучше учесть.
В блоках catch() старайтесь отлавливать сперва конкретные типы исключений, а не все сразу ( catch(…){} ). Воспринимайте catch() не как неприятную обязанность по отношению к стандарту, а как средство побольше узнать о причине исключений и их типе.
Если в описании функции не стоит списка типов исключений, которые она генерирует, это не значит, что она не сможет их сгенерировать. Просто в этом случае компилятору разрешено прибить программу.
Если вызываемая функция возвращает значение и в нем может быть код ошибки, надо проверять это значение.
Если есть сравнение строк, например (m_name==”text”), то возможно получится сделать его более эффективным используя утилиту gperf (когда нужно определить попадание строки в какое-то конечное множество строк).
При сравнении длины строки вместо сравнения (strlen(buf)>0) эффективнее будет использовать такой вариант: (*buf != 0)
Если не предполагается изменять в теле функции параметр-ссылку (&), то лучше передавать ее константной. Пусть имеется объявление функции:
void some_func(int& parm) {...}
Если в теле функции содержимое param не изменяется, то лучше написать так:
void some_func(const int& parm) {...}
В каждой строке должно быть одно сравнение, оператор или вызов функции. Это пригодится при отладке кода в GDB – проще найти что именно в сбойной строке работает не так.
Помните что при сравнении строк strcmp() учитывает регистр, а strcasecmp() — нет.
Типы данных и функции из STL должны начинаться с std:: Это предотвратит потенциальную путаницу с пространствами имен

Подписаться на комментарии

Tamkovich.com: Телеком/VoIP блог

Современные технологии: Asterisk, SIP, Kamailio, Linux, Cisco, Linksys

Рубрики

Метки

Мета

Комментарии