Tamkovich.com: Телеком/VoIP блог
Современные технологии: Asterisk, SIP, Kamailio, Linux, Cisco, Linksys
Типичные комментарии к коду на С++, выставляемому на ревью
7 июня, 2011 by rius
Программирование C++При разработке ПО командой программистов как правило используется одна из систем контроля версий. Для того, чтобы внести свои изменения в репозиторий, члену команды нужно получить одобрение нескольких авторитетных разработчиков. Они могут подсказать более эффективный вариант или подсказать неочевидные побочные эффекты вашего варианта кода. Часто к первой ревизии изменений разработчик получает комментарии, которые он должен учесть при выставлении следующей ревизии на ревью.
Опустим совсем уж нелепые ошибки и неточности (магические числа и пр) в коде. Про подобные вещи можно прочитать, например, в книге «Совершенный код» Макконнелла. А вот специфичные для программ написанных на 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:: Это предотвратит потенциальную путаницу с пространствами имен
Программирование C++