Всем привет,

Может ли кто поделиться примером корпоративного стандарта программирования на C/C++?

С уважением.

Ты имеешь ввиду оформление кода или что-то иное?

Именно, просто чтоб было прилично оформлено. Хочу знать на что профессионалы ориентируются
Добавлено спустя 7 часов, 25 минут, 52 секунды
Я хочу док для программеров на фирме. Как им правильно писать код на C++

Типа как http://www.gridlab.org/WorkPackages/tec ... ng_cpp.pdf но по русски.
Добавлено спустя 11 часов, 31 минуту, 52 секунды

Вот написал свой вариант стандарта, буду рад учесть ваши замечания.

Скачать здесь: http://www.cubereality.ho.com.ua/CPPCodingRules.rtf

CubeReality
Позволь выразить некоторую критику:


Если речь идёт об объявлении в классе, то да - лучше всегда. Если у тебя некоторая локальная переменная в функции с именем numberOfCoins скажем, то зачем для неё комментарий, если имя полностью задаёт семантику.

То есть будешь писать singned int, signed char, забавно

идиотизм Я могу лишь сказать такое про enum, для class и struct это вредит, имхо.

Совершенно спорный вопрос, ибо в некоторых случаях можно формально доказать, что break или return обязательно выполнится, следовательно можно использовать без угрызения совести.

Смелое допущение обычно его никто не разрешает использовать, тем более ни у кого и желания то нет

чем плох оператор ?

Опять же, в некоторых случаях можно доказать, что глубина рекурсии не превзойдёт какуюто функцию, поэтому я бы сказал её нужно использовать, если это упрощает дело, некоторые рекурсивные алгоритмы более легко читаемы.

К остальному претензий не имею , но думаю, другие люди их там найдут обязательно.

Если номера строк сдвинуться, то может нехорошо получиться, когда комментарий обновить забудешь...

Так какая разница где условие выхода: в начале,в середине или в конце цикла? Условие может выполниться или не выполниться в любом случает и это на совести программиста.

Честно говоря не осилил до конца прочесь файл. Но скажу к примеру по своему опыту. Я работал в группах, писали мы и большие и маленькие софты. Когда сменялся программер, то часто было так, что новому разобратся в коде было тяжело, но не невозможно! Мы просто отшивали таких программеров на стадии принятия на работу! Любой нормальный программист, спокойно разберется в коде если этот код был написан нормальным программистом.
Мы чаще всего ставили условия не как оформлять код, а как применять те или иные технологии. К примеру лично я сильно бил по рукам особо рьяных программеров, помешанных на ООП. Так как уже было два больших показательных примера, когда слишком заумное применение ООП приводило к тому, что весь код переписывался по новой.
В любом случае в больших группах программистов тон обычно задают главные программисты, которые обычно уже имеют большой опыт программирования в группах. Ну это я конечно в идеале описываю, сами знаете как у нас иногда бывает Все как говорится через одно место.

Но в любом случае. Даже в группе их двух человек надо обязательно обговаривать как и что должно писаться. Не надо насильно заставлять делать что-то по другому. Если один любит писать переменные в Венгерской нотации, а другой в другой. То не надо их мучать, пусть только имена дают осмысленные и все

Не понял , к чему вообще сказано про концы и началы. Я имел в виду, что если прог уверен, что не зациклится,то юзать можно.

Так я именно это и имел ввиду. Сам постоянно пользуюсь конструкцией: