Кроссплатформенный открытый движок на Java, позволяющий создавать 2D и 3D игры под различные платформы, среди которых: Android, HTML5, Windows, Linux, iOS.
Поддержи проект!
Рекомендуем
Блог разработчика
Главная » 2010 » Декабрь » 22 » Некоторые рекомендации по оформлению кода на C++
1:00 AM
Некоторые рекомендации по оформлению кода на C++
1. Весь код должен соответствовать ANSI-стандарту.
2. Желательно использовать уникальный префикс для имен всех файлов и классов проекта.
3. Имена аргументов функций (методов) начинаются с префикса:
i - для входных аргументов; o - для выходных аргументов; io - для аргументов, которые одновременно используются для ввода и вывода.
4. Все переменные пишутся с маленькой буквы, пример: int objectsCount;
5. Все функции пишутся с большой буквы: int CreateObject();
6. Имена методов и функций начинаются с глаголов, например:
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).