Repository navigation
Cpp Code Style
###Сведены Google and Blink C++ code style в один. Еще можно полистать "Стандарты кодирования С++".
- http://www.chromium.org/blink/coding-style
- http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
- https://www.securecoding.cert.org/confluence/display/cplusplus/00.+Introduction - CERT code standart
Нравится в Google:
-
Имена файлов (*.cc, *.h, *_test.cc)
-
include но до конца не понял и тут(Use standard order for readability and to avoid hidden dependencies - how?) и в Blink но про "config.h" в Блинк очень важно - уже думал как такую проблему решить, а тут вот она решена. см. http://www.chromium.org/developers/coding-style/cpp-dos-and-donts
-
Avoid doing complex initialization in constructors - отдельно выделю, а то бросал исключения в констр. Лучше передать сконструированные объекты, через DI. Плюс это улучшает тестабильность. Инициализация сырых и умных указателе не бросает исключений
-
Interfaces naming
-
Имена полей класса - Typically a variable would be called foo_ and the accessor function foo(). You may also want a mutator function set_foo().
-
DISALLOW_COPY_AND_ASSIGN
-
Make data members private, and provide access to them through accessor functions as needed - для тестироания самое оно. Позволяет внедрять зависимости.
-
cpplint
-
Имена констант
-
Do not use Hungarian notation
Не нравится в Google:
-
Запрет исключений. А что в замен - вот это проблема? Коды ошибок? Decision: We use C++ exceptions. Exception safety requires both RAII and different coding practices. Но вообще - если используешь коды ошибок - ясно когда код плох, но вот отличить код, безопасный в плане искл. от опасного на вид трудно.
-
имена переменных, хотяя... они как в питоне. Нет нотация имени переменной должна совпадать с нотацией метода, иначе выглядит плохо
Нравится в Blink:
- Constructor Initializer Lists
- "config.h" файл в cpp
- Java naming
- s_ для статических полей класса - вообще-то такие поля в принципе лучше не использовать
- using внутри классов, но в заголовке, иначе очень захламлен интерфейс - нет все равно не рекомендуют.
- Null, false and 0 - как в питоне
Не нравится в Blink:
- indent 4 spaces. Для Python да - там важен отступ - тут думаю нет.
- m_ для полей класса
- названия макросов и защиты от повторного включения
- TODO
- switch - уж очень непривычно
- std:: everywhere
Не нравится в 'Стандартах кодирования С++':
- нельзя использовать using in headers, хотя... Не обсуждается! Нельзя и точка
###Итого:
- За основу GoogleStyle, он более подробный и обоснованный
- Используем исключение, а значить нужно писать безопасный в плане исключений код - замки, смарт-поинтеры и т.п.
- В заголовок любого реализационного файла проекта(*.cc), не библиотечного и не реюзабильного включеть "config.h" - первым!
- Имена переменных и методов как в Java - someField_ (private) someField__ protected - s_someField - статические данные - лучше не использовать.
- Поля лучше делать константными!
- Имена Глобальных функций - FunctionDoSomething
Нашел еще один