Некоторые рекомендации по оформлению кода на C++
Материал из LinTest Wiki
Версия от 09:53, 19 августа 2009; Admin (обсуждение | вклад)
1. Весь код должен соответствовать ANSI-стандарту. 2. Желательно использовать уникальный префикс для имен всех файлов и классов проекта. 3. Имена аргументов функций (методов) начинаются с префикса: i - для входных аргументов; o - для выходных аргументов; io - для аргументов, которые одновременно используются для ввода и вывода. 4. Все переменные пишутся с маленькой буквы, пример: int objectsCount; 5. Все функции пишутся с большой буквы: int CreateObject(); 6. Имена методов и функций начинаются с глаголов, например: size_t Size(); // неправильно; size_t GetSize(); // правильно. 7. Макросы и только макросы пишутся целиком заглавными буквами. 8. Члены класса начинаются с префикса m_, статические члены - с префикса sm_. 9. Описание (декларация) класса находится в h-файле с тем же именем, что и имя класса. Например, описание класса CList находится в файле CList.h. Естественно, что несколько родственных и небольших классов разумнее (удобнее) размещать в одном хедере. 10. Реализация методов класса находится в cpp-файле с тем же именем, что и имя класса; исключения: реализация является целиком inline-овой, класс шаблонный, несколько мелких родственных классов. 11. Имена переменных, функций, классов должны чётко отражать главный концептуальный смысл обозначаемого, а не какой-то из реализационных аспектов (как это часто бывает). 12. В начале каждого файла идет "шапка", содержащая в себе: комментарий, дающий краткое описание данного файла, а также имя автора, время создания, модификации файла, etc. Пример шапки: /****************************************************************************** * File: McEndPointMessage.h * Description: The message to exchange data between EndPoints. * Created: 01 jan 2007 * Copyright: (C) 2007 Top Secret Lab * Author: Basil Pupkin * Email: v_pupkin@tsl.com ******************************************************************************/ 13. Документирование кода лучше сразу делать в формате, пригодном для автоматической генерации документации, например, программой doxygen. 14. Перед декларацией каждого класса идет комментарий, описывающий данный класс, пример: /** * @class McEndPointMessage * The inter-process message to exchange data between EndPoints. * @note AllData = Code (2 first bytes) + Content */ class McEndPointMessage { ... } 15. Перед описанием каждого метода идет описывающий его комментарий, пример: /** * Assign all data from buffer. * @param iData - buffer where will copy from. * @param iSize - size of the iData buffer. * @return true if successful, false indicates invalid argument(s). * @note The iData buffer is not validated for correctness. */ bool SetAllDataFromBuffer( t_byte const * iData, size_t iSize ); 16. Описание класса начинается с его public-раздела. 17. В заголовочных файлах должно быть минимальное количество директив #include. 18. Очень рекомендуется делать отступы с помощью tab-ов, а не с помощью пробелов. 19. Очень не рекомендуется экономить на пробелах: t_errno CreatePB(UcNet const *iNet,UcBArray *ioTransBlock); //плохо t_errno CreatePB (UcNet const *iNet, UcBArray *ioTransBlock); //лучше t_errno CreatePB( UcNet const * iNet, UcBArray * ioTransBlock ); //ещё лучше :) 20. При сборке проекта не должно быть warning-ов (level 3).