Как такового стандарта оформления кода нет - у каждого он свой. И пытаться навязать какие-то рамки мне бы не хотелось. Надо иметь в виду, что какой бы вы способ оформления ни выбрали, вы должны следовать ему как минимум в пределах одного файла. Но лучше, когда во всем проекте только один стиль.
Рассмотрим только общее, что объединяет стандарты.

1. На одной строке должна располагаться только одна операция
Это правило очень сильно упрощает понимание кода и его отладку.
Еще можно добавить сюда же требование объявлять переменные отдельно друг от друга:
2. Названия типов, функций, переменных и пр. должны отражать их суть
Если дать переменной название v, то через пол года никто не сможет понять без заглядывание в код, за что она отвечает. Конечно, если у вас есть цикл на пару строчек, то переменную-счетчик целого типа можно называть просто: i, j, k...
Хорошо оформленный код легко позволяет определить, чем является каждый конкретный символ - одного взгляда достаточно, чтобы, например, отличить функцию от имени класса. Легче всего этого добиться при использовании разных регистров символов. Например:
3. Отступы делать обязательно
Всегда нужно выделять отступами блоки кода, которые выполняются в зависимости от встроенных операторов (циклов, условий). Это сильно упрощает отлов тривиальных ошибок (например, когда нужно выполнение нескольких операций в цикле, не заключенных в фигурные скобки). Например:Отступы делают пробелами или символом табуляции, иногда и тем и другим одновременно. Хочу предостеречь от последнего - всегда делайте отступы только пробелами, или только табуляцией, так как в противном случае весь код расползается при изменении размера символа табуляции - такой код читать очень сложно при других настройках редактора. Некоторые современные среды программирования позволяют автоматически преобразовывать символы табуляции в пробелы и обратно. Таким образом, сохраненный файл всегда имеет отступы в виде пробелов, тогда как в редакторе отступы в виде табуляций.
По умолчанию, символ табуляции имеет размер эквивалентный восьми пробелам. Его использование приводит к тому, что довольно быстро теряется свободное место для кода в строке... С другой стороны, на отступ в один пробел сложно ориентироваться. Поэтому лично я предпочитаю размер отступа равным четырем пробелам. Это компромисс между наглядностью и плотностью текста.
В пределах одного файла (а желательно и всего проекта) нужно придерживаться одного размера отступа. Т.е. чтобы не было, что тело одной функции сдвинуто на 4 пробела от начала строки, а тело другой (равноценной) - на 8.

4. Правило расстановки фигурных скобок должно быть одно для всего файла
Тут опять же четко не определено, как и где их ставить. Но наиболее популярные:
- открывающая на строке оператора:
- открывающая на следующей строке:
При этом, закрывающая фигуная скобка всегда ставится на новой строке и отступ пред ней такой же, как и перед строкой, на которой стоит открывающая.
Возможны смешанные варианты, когда в одних случаях используется одна схема, а в других - другая. Например, стиль Linux:
5. Не скупитесь на пустые строки
Очень часто в одной функции выполняется последовательность неких действий, каждое из которых состоит из нескольких вызовов. Очень хорошо смотрится код, в котором эти действия разделены пустыми строками. Так же, в данном случае не помешает комментарий на пару слов, дающий общее представления о действии, которое идет ниже.
6. Большие функции - это зло
Хорошим стилем программирования считается, когда у вас функция имеет размер не более трёх десятков строк. Конечно, бывают случаи, когда сложный алгоритм не позволяет безвредно разбить функцию на несколько. Но они случаются крайне редко. Поэтому, если у функции получилось большое тело, то надо ее разделять на составные. Выделять стоит в первую очередь то, что в последствии можно будет использовать отдельно.

7. Не стоит делать функции с более чем 3-мя параметрами
Чем больше параметров, тем сложнее запомнить, что и в какой последовательности надо передавать. Иногда помогает разбиение на несколько функций, иногда - объединение параметров связанных по смыслу в структуры.

8. Узкоспециализированные функции/классы предпочтительней универсальным
Предположим, вам нужно сегодня перевезти пару сумок вещей на дачу. Завтра может понадобиться перевести 20 тонн угля из карьера с Урала. Вы подумали и решили, что лучше всего проложить железную дорогу от дома до дачи и перевезти сумки на товарном поезде со специальным вагоном для сумок, который завтра будете использовать для перевозки угля...
Так примерно рассуждают те, кто пишет универсальные функции, которые "и швец, и жнец, и на дуде игрец". На самом деле, эти функции очень не удобны как при разработке, так и при использовании (Например, функция CreateFile из WinAPI32, согласитесь, что использовать этого монстра для простого открытия файла на чтение очень "весело"). Поэтому пишите простые функции, которые выполняют только одно действие, которое можно описать не более чем тремя словами (они то и составят ее название).

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

10. Не пренебрегайте использованием const
Это из разряда "предпочитайте ошибки компиляции ошибкам исполнения". Смысл этого модификатора в том, чтобы указать компилятору, что переменная не будет меняться. Поэтому, если где-то ее попытаться изменить, то компилятор тут же даст по рукам. Более того, это повышает самодокументируемость кода, так как дает некие гарантии.

11. Предпочитайте простые условия сложным
Если простейшая комбинация (i > 0) && (i < 10) читается и понимается легко, то "трёхэтажные" очень сложно разобрать. Поэтому рекомендуется их упрощать путем присваивания промежуточных значений временным переменным:

12. Не забывайте комментировать код
Далеко не всегда удается писать самодокументируемый код. В этом случае следует комментировать некоторые сложные и неочевидные действия программы, когда они не выделены в отдельную функцию с говорящим названием. Например, есть некий код, который что-то считает по сложной формуле. Эта формула разбита на 10 частей. Причем, каждая часть считается, например, по ряду Тейлора, таким образом быстрого взгляда на код не достаточно, чтобы понять, что он делает (кто знает, что это такое ряд Тейлора, тот поймет). Поэтому, нужно перед каждой такой частью написать комментарий о том, что именно эта часть считает, понятным языком, в данном случае, математическим.

Не надо писать комментарии вида:

• "подключаем заголовочный файл xxx" в строке #include <xxx>
• "объявляем переменную x типа int" в строке int x
• "объявляем массив y из 10 элементов типа float" в строке float y[10];
• "реализуем функцию main" в строке int main()

Так как очевидно, что тут делается.

Итак, вот пример правильно оформленного (кроме пункта 12) кода:Так как данный код не несет в себе хоть какой-нибудь смысловой нагрузки, то в нем нет отделения блоков кода пустыми строками. В реальном коде они очень желательны.

Если есть желание узнать больше, то рекомендую прочитать книги:

• Г. Саттер, А. Александреску - Стандарты программирования на С++
• С. Макконнелл - Совершенный код

Назад к FAQ

Это сообщение отредактировал(а) bsa - 26.7.2011, 11:00

компилятору не понравится такое  

не поделитесь секретом, почему это вдруг не понравится ?

перепечатка "Стандарты программирования на С++", Александреску, Саттер ?

не хватает return

Скорей изложение своими словами. У нас же книжек никто не читает, а тут можно будет уже тыкать носом.

andrew_121
спасибо. исправил.


Замечания и пожелания приветствуются!

bsa, список использованной литературы бы указал
а то я те же самые слова в "стандартах" вижу, 1к1

я бы такой совет дал: давать имя логическому условию, а не "тупо" определять его.

Пример:
было:

стало:

***
а вообще очень много советов по форматированию кода/его правильному написанию есть в книге Макконнелла "Совершенный код"

Это сообщение отредактировал(а) zim22 - 16.8.2009, 19:10

Как насчет использования подчеркиваний в переменных?  (что мне жутко не нравится)
Когда юзается? в контролах? 

Если видишь совпадения, то приведи номера страниц. Я пролистал эту книжку и ничего подходящего не нашел.
Саттера и Александреску приводить не хочу, так как эта книга для новичков еще рановата.

и вообще насчет использования подчеркиваний в именах.

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

Добавлено через 6 минут и 26 секунд
Madonna, если ты обратила внимание, в приведенном мной примере подчеркивание используется только для макроопределений. Сейчас еще добавлю класс с приватными атрибутами. Я, например, буду использовать подчеркивание только в случае невозможности применения CamelCase (разделение слов регистром). Т.е. my_super_proc смотрится гораздо лучше, чем mysuperproc. С другой стороны: My_Cool_Type - выглядит коряво, имхо.

нет 
это понятно. В этой статье очень хорошо описано http://rsdn.ru/article/mag/200401/codestyle.XML

Меня интереуют другие случае, т.е. в сpp коде оправданы (по вашему мнению удобно использовать) подчеркивания. например some_variable (вместо как мне кажется более удобной кемел-нотации), m_variable.
 

Madonna, enum-ы часто так делают, т.к. по сути своей они определяют константы и стиль их использования НЕ EnumName::EnumValue.


я обычно обертывают такой enum в struct, чтобы было использоание в виде struct::S_OK. При этом конструктор в struct и деструктор приватные конечно 8)

Madonna, если честно, я не люблю именования some_variable... Так как тут не очень очевидно, тип это или переменная.

я обратила внимание. 

Т.е. лучше использовать разделение регистром. 
Просто чаще видела подчеркивания в cpp коде и совершенно их не видела в c# коде. Видимо наследие чистого С.

Даже например здесь http://www.codeproject.com/KB/miscctrl/mcppwinforms01.aspx используется m_label.  Т.е. для контролов. Сейчас зашла на сайт троллей, используют просто label.

Всем спасибо.

a почему не в namespace ?

Добавлено через 1 минуту и 6 секунд
P.S. о тут уже написали.

Добавлено через 3 минуты и 43 секунды

добавлю как имхо: зачастую только логичнее будет определить функцию с таким именем как в примере, чем просто определять переменную.

ну не знаю. от ситуации зависит. как по мне - переменная lineVisible лучше, чем функцию с 3 параметрами

***
хотя если эта функция вызываться будет более одного раза - то функция лучше. т.к. код не будет повторяться. 

Это сообщение отредактировал(а) zim22 - 16.8.2009, 20:15

с 2мя, номер линии и контекст(документ)

zim22 и mes, согласен, что трех-этажные условия - это плохо. Вы действительно считаете, что его разбивание надо воткнуть в статью?

Добавлено через 1 минуту и 5 секунд
Madonna, m_label, если мне память не изменяет, это еще один вариант именования приватных атрибутов. Говорю же, на вкус и цвет...

я бы воткнул. как по мне - от этого только польза будет.
***
а самая огромная польза я считаю будет, если следовать принципу DRY(Don't Repeat Yourself) (Не повторяй самого себя).
из книги "Программист-прагматик". 7. Пороки дублирования.

Потому что очень невесело рефакторить код из 1000 строк, в результате сократив его до 100. Причина: повторяющиеся куски кода не были вынесены в функции, а тупо тиражировалось тело функции 15 раз. Только параметры отличались.

Это сообщение отредактировал(а) zim22 - 16.8.2009, 21:40

  а что означает m_ ?

[offtopic]

Документацию генерировать в С++ можно?

Навеяно http://forum.vingrad.ru/forum/topic-269502...0%BE%D0%BF.html

[/offtopic]

Madonna, что означет m_ не знаю. Просто некая приставка.

Документацию генерировать можно например с помощью doxygen. Вот только какое это отношение имеет к обсуждаемой статье?

Madonna, Венгерская нотация



Соглашения по оформлению кода команды RSDN

Madonna, XML-документация в С++ есть
http://msdn.microsoft.com/en-us/library/ms177226(VS.80).aspx

А почему в namespace? Чем namespace лучше структуры или класса?

В список литературы также "Практика программирования" Кернигана. Без проблем находится в сети.

FiMa1, сенкс

Номально.

Кандидат на добавление: совет по комментированию кода. Навеяно этой темой. 

Суть примерно такова: при добавлении комментариев считайте, что читать код в будующем будет более опытный программист. Возможно это будете Вы некоторое время спустя. Поэтому не стоит комментировать очевидные и понятные вещи, типа:


Мопед не мой! (с)

kemiisto, сделал