Некоторые рекомендации по оформлению кода на C++

Материал из LinTest Wiki
Версия от 16:15, 27 июля 2014; 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).

Персональные инструменты
Пространства имён

Варианты
Действия
Навигация
Инструменты
Проекты