1.8 – Пробельные символы и базовое форматирование кода
Пробельный символ – это термин, обозначающий символы, которые используются для форматирования. В C++ это в первую очередь относится к пробелам, табуляциям и символам новой строки. Компилятор C++ обычно игнорирует пробелы, за некоторыми незначительными исключениями (при обработке текстовых литералов). По этой причине мы говорим, что C++ – это язык, не зависящий от пробелов.
Следовательно, все следующие выражения делают одно и то же:
Даже последнее выражение, разбитое на две строки, компилируется нормально.
Следующие функции выполняют одно и то же:
Одно исключение, когда компилятор C++ обращает на них внимание, это, когда пробельные символы находятся внутри текста в кавычках, например "Hello world!" .
и каждый из них распечатывается именно так, как вы ожидали.
В тексте, заключенном в кавычки, переносы на новую строку не допускаются:
Фрагменты текста в кавычках, разделенные только пробельными символами (пробелы, табуляции или новые строки), будут объединены:
Другое исключение, когда компилятор C++ обращает внимание на пробелы, – это комментарии с // . Однострочные комментарии продолжаются только до конца строки. Таким образом, если вы сделаете что-то вроде этого, у вас возникнут проблемы:
Базовое форматирование
В отличие от некоторых других языков, C++ не накладывает на форматирование для программиста никаких ограничений (помните, доверяйте программисту!). На протяжении многих лет было разработано множество различных методов форматирования программ на C++, и вы обнаружите разногласия по поводу того, какие из них лучше. Наше основное эмпирическое правило состоит в том, что лучшие стили – это те, которые создают наиболее читаемый код и обеспечивают наибольшую последовательность.
Ниже приведены наши рекомендации по базовому форматированию:
1) Для отступов можно использовать табуляцию или пробелы (в большинстве IDE есть параметр, позволяющий преобразовать нажатие табуляции в соответствующее количество пробелов). Разработчики, которые предпочитают пробелы, как правило, делают это, потому что пробелы делают форматирование самоописывающим – код, разделенный пробелами, всегда будет выглядеть правильно, независимо от редактора. Сторонники использования табуляций задаются вопросом, почему бы вам для отступов не использовать символ, предназначенный для создания отступов, тем более что вы можете установить ширину по своему усмотрению. Здесь нет правильного ответа – и спорить об этом всё равно, что спорить, что лучше – торт или пирог. В конечном итоге всё сводится к личным предпочтениям.
В любом случае мы рекомендуем вам установить для табуляций значение отступа в 4 пробела. Некоторые IDE по умолчанию используют отступ в 3 пробела, что тоже нормально.
2) Есть два приемлемых стиля для фигурных скобок.
Руководство по стилю Google C++ рекомендует ставить открывающую фигурную скобку в той же строке, что и выражение:
Обоснованием этого является то, что это уменьшает количество вертикальных пробельных символов (вы не посвящаете всю строку ничему, кроме открывающей фигурной скобки), поэтому вы можете разместить больше кода на экране. Больше кода на экране упрощает понимание программы.
Однако мы предпочитаем распространенный вариант, когда открывающая фигурная скобка располагается в отдельной строке:
Это улучшает читаемость и снижает вероятность ошибок, поскольку пары скобок всегда должны иметь один и тот же отступ. Если вы получаете ошибку компилятора из-за несоответствия скобок, очень легко увидеть, где именно допущена ошибка.
3) Каждое выражение в фигурных скобках должно начинаться на одну табуляцию дальше от открывающей фигурной скобки функции, которой оно принадлежит. Например:
4) Строки не должны быть слишком длинными. Как правило, максимальная длина строки составляет 80 символов. Если строка будет длиннее, ее следует разделить (в разумном месте) на несколько строк. Это можно сделать, добавив к каждой последующей строке дополнительную табуляцию, или, если строки похожи, выровняв ее по строке выше (в зависимости от того, что легче читается).
Это облегчает чтение ваших строк. На современных широкоэкранных мониторах он также позволяет разместить два окна с похожим кодом рядом, что упрощает их сравнение.
Лучшая практика
Длина ваших строк не должна превышать 80 символов.
5) Если длинная строка разделена оператором (например, << или + ), оператор должен быть помещен в начало следующей строки, а не в конец текущей строки.
Это помогает прояснить, что последующие строки являются продолжением предыдущих строк, и позволяет выровнять операторы слева, что упрощает чтение.
6) Используйте пробельные символы, чтобы облегчить чтение кода, выравнивая значения и комментарии и добавляя интервалы между блоками кода.
Следующий код читать сложнее:
А этот код читать легче:
Мы будем следовать этим соглашениям на протяжении всех уроков, и они станут вашей второй натурой. По мере того, как мы представляем вам новые темы, мы будем предлагать новые рекомендации по стилю оформления для этого нового функционала.
В конечном итоге C++ дает вам возможность выбрать тот стиль, который вам больше всего подходит, или который вы считаете лучшим. Однако мы настоятельно рекомендуем вам использовать тот же стиль, который используем мы в наших примерах. Он был протестирован тысячами программистов над миллиардами строк кода и оптимизирован для достижения успеха. Одно исключение: если вы работаете с чужим кодом, перенимайте его стили. Лучше отдать предпочтение последовательности, чем вашим предпочтениям.
Автоматическое форматирование
Большинство современных IDE помогут вам отформатировать код по мере его ввода (например, когда вы создаете функцию, IDE автоматически делает отступы для выражений внутри тела функции).
Однако когда вы добавляете или удаляете код, или изменяете форматирование IDE по умолчанию, или вставляете блок кода с другим форматированием, форматирование может испортиться. Исправление форматирования для фрагмента или всего файла может вызывать головную боль. К счастью, современные IDE обычно содержат функцию автоматического форматирования, которая переформатирует либо выделенный фрагмент (выделенный мышью), либо весь файл.
Для пользователей Visual Studio
В Visual Studio параметры автоматического форматирования можно найти в меню Правка (Edit) → Дополнительно (Advanced) → Форматировать документ (Format Document) и Правка (Edit) → Дополнительно (Advanced) → Форматировать выделенный фрагмент (Format Selection).
Для пользователей Code::Blocks
В Code::Blocks параметры автоматического форматирования можно найти в меню клик правой кнопкой мыши в любом месте редактора → Format use AStyle (Форматировать с использованием AStyle).
Для облегчения доступа к этим функциям мы рекомендуем добавить сочетание клавиш для автоматического форматирования активного файла.
Лучшая практика
Для сохранения единообразия стиля форматирования кода настоятельно рекомендуется использовать функцию автоматического форматирования.
Задать отступы в RichTextBox
Как сделать отступы от края RichTextBox до текста? Эти отступы должны быть всегда, так как текст по умолчанию находится слишком близко к краю RichTextBox . Пример на картинке.
RichTextBox не имеет такого свойства.
Быстрое решение может быть достигнуто путем помещения RichTextBox в Panel , которая имеет такое же свойство BackColor , что и RichTextBox (обычно Color.White ).
Затем установите свойство Dock для RichTextBox для заполнения и задайте через свойство Padding контрола Panel необходимый отступ.
Расширьте методы RichTextBox :
Дальше в Form_Load используйте добавленные методы:
См. свойства SelectionIndent , SelectionRightIndent , SelectionHangingIndent .
Это обеспечит отступ в 50 пикселей для всего текста от левого края контрола.
Руководство Google по стилю в C++. Часть 10
Часть 1. Вступление
…
Часть 9. Комментарии
Часть 10. Форматирование
Часть 11. Исключения из правил 
Эта статья является переводом части руководства Google по стилю в C++ на русский язык.
Исходная статья (fork на github), обновляемый перевод.
Форматирование
Стиль кодирования и форматирования являются вещью произвольной, однако проект намного легче управляется, если все следуют одному стилю. Хотя кто-то может не соглашаться со всеми правилами (или пользоваться тем, чем привыкли), очень важно чтобы все следовали единым правилам, чтобы легко читать и понимать чужой код.
Для корректного форматирования мы создали файл настроек для emacs.
Длина строк
Желательно ограничивать длину строк кода 80-ю символами.
Это правило немного спорное, однако масса уже существющего кода придерживается этого принципа, и мы также поддерживаем его.
За
Приверженцы правила утверждают, что строки длиннее не нужны, а постоянно подгонять размеры окон утомительно. Кроме того, некоторые размещают окна с кодом рядом друг с другом и не могут произвольно увеличивать ширину окон. При этом ширина в 80 символов — исторический стандарт, зачем его менять.
Другая сторона утверждает, что длинные строки могут улучшить читабельность кода. 80 символов — пережиток мейнфреймов 1960-х. Современные экраны вполне могут показывать более длинные строки.
80 символов — максимум.
Строка может превышать предел в 80 символов если:
- комментарий при разделении потеряет в понятности или лёгкости копирования. Например, комментарий с примером команды или URL-ссылкой, длиннее 80 символов.
- строковый литерал/имя, длиной более 80 символов. Исключением является тестовый код, который желательно размещать в начале файла.
- выражения с include.
- Блокировка от повторного включения
- using декларации
Не-ASCII символы
Не-ASCII символы следует использоваться как можно реже, кодировка должна быть UTF-8.
Вы не должны хардкодить строки для показа пользователю (даже английские), поэтому Не-ASCII символы должны быть редкостью. Однако, в ряде случаев допустимо включать такие слова в код. Например, если код парсит файлы данных (с неанглийской кодировкой), возможно включать в код национальные слова-разделители. В более общем случае, код юнит-тестов может содержать национальные строки. В этих случаях следует использовать кодировку UTF-8, т.к. она понятна большинству утилит (которые понимают не только ASCII).
Кодировка hex также допустима, особенно если она улучшает читабельность. Например, «\xEF\xBB\xBF» или u8″\uFEFF» — неразрывный пробел нулевой длины в Юникоде, и который не должен отображаться в правильном UTF-8 тексте.
Используйте префикс u8 чтобы литералы вида \uXXXX кодировались в UTF-8. Не используйте его для строк, содержащих не-ASCII символы уже закодированные в UTF-8 — можете получить корявый текст если компилятор не распознает исходный код как UTF-8.
Избегайте использования символов C++11 char16_t и char32_t т.к. они нужны для не-UTF-8 строк. По тем же причинам не используйте wchar_t (кроме случаев работы с Windows API, использующий wchar_t).
Пробелы против Табуляции
Используйте только пробелы для отступов. 2 пробела на один отступ.
Мы используем пробелы для отступов. Не используйте табуляцию в своём коде — настройте свой редактор на вставку пробелов при нажатии клавиши Tab.
Объявления и определения функций
Старайтесь размещать тип возвращаемого значения, имя функции и её параметры на одной строке (если всё умещается). Разбейте слишком длинный список параметров на строки также как аргументы в вызове функции.
Пример правильного оформления функции:
В случае если одной строки мало:
или, если первый параметр также не помещается:
- Выбирайте хорошие имена для параметров.
- Имя параметра можно опустить, если он не используется в определении функции.
- Если тип возвращаемого значения и имя функции не помещаются в одной строке, тип оставьте на одной строке, имя функции перенесите на следующую. В этом случае не делайте дополнительный отступ перед именем функции.
- Открывающая круглая скобка всегда находится на одной строке с именем функции.
- Не вставляйте пробелы между именем функции и открывающей круглой скобкой.
- Не вставляйте пробелы между круглыми скобками и параметрами.
- Открывающая фигурная скобка всегда в конце последней строки определения. Не переносите её на новую строку.
- Закрывающая фигурная скобка располагается либо на отдельной строке, либо на той же строке, где и открывающая скобка.
- Между закрывающей круглой скобкой и открывающей фигурной скобкой должен быть пробел.
- Старайтесь выравнивать все параметры.
- Стандартный отступ — 2 пробела.
- При переносе параметров на другую строку используйте отступ 4 пробела.
Неиспользуемый параметры с неочевидным контекстом следует закомментировать в определении функции:
Атрибуты и макросы старайтесь использовать в начале обьявления или определения функции,
до типа возвращаемого значения:
Лямбды
Форматируйте параметры и тело выражения аналогично обычной функции, список захватываемых переменных — как обычный список.
Для захвата переменных по ссылке не ставьте пробел между амперсандом (&) и именем переменной.
Короткие лямбды можно использовать напрямую как аргумент функции.
Числа с плавающей запятой
Числа с плавающей запятой всегда должны быть с десятичной точкой и числами по обе стороны от неё (даже в случае экспоненциальной нотации). Такой подход улучшить читабельность: все числа с плавающей запятой будут в одинаковом формате, не спутаешь с целым числом, и символы E e экспоненциальной нотации не примешь за шестнадцатеричные цифры. Помните, что число в экспоненциальной нотации не является целым числом.
Вызов функции
Следует либо писать весь вызов функции одной строкой, либо размещать аргументы на новой строке. И отступ может быть либо по первому аргументу, либо 4 пробела. Старайтесь минимизировать количество строк, размещайте по несколько аргументов на каждой строке.
Формат вызова функции:
Если аргументы не помещаются в одной строке, то разделяем их на несколько строк и каждая следующая строка выравнивается на первый аргумент. Не добавляйте пробелы между круглыми скобками и аргументами:
Допускается размещать аргументы на нескольких строках с отступом в 4 пробела:
Старайтесь размещать по несколько аргументов в строке, уменьшая количество строк на вызов функции (если это не ухудшает читабельность). Некоторые считают, что форматирование строго по одному аргументу в строке более читабельно и облегчает редактирование аргументов. Однако, мы ориентируемся прежде всего на читателей кода (не редактирование), поэтому предлагаем ряд подходов для улучшения читабельность.
Если несколько аргементов в одной строке ухудшают читабельность (из-за сложности или запутанности выражений), попробуйте создать для аргументов «говорящие» переменные:
Или разместите сложный аргумент на отдельной строке и добавьте поясняющий комментарий:
Если в вызове функции ещё есть аргументы, которые желательно разместить на отдельной строке — размещайте. Решение должно основываться улучшении читабельность кода.
Иногда аргументы формируют структуру. В этом случае форматируйте аргументы согласно требуемой структуре:
Форматирование списка инициализации
Форматируйте список инициализации аналогично вызову функции.
Если список в скобках следует за именем (например, имя типа или переменной), форматируйте <> как будто это вызов функции с этим именем. Даже если имени нет, считайте что оно есть, только пустое.
Условия
Старайтесь не вставлять пробелы с внутренней стороны скобок. Размещайте if и else на разных строках.
Есть два подхода к форматированию условий. Один допускает пробелы между скобками и условием, другой — нет.
Предпочтительный вариант без пробелов. Другой вариант также допустим, но будьте последовательны. Если вы модифицируйте существующий код — используйте формат, который уже есть в коде. Если вы пишете новый код — используйте формат как у файлов, находящихся в той же директории или используйте формат проекта. Если не уверены — не добавляйте пробелы.
Если используется формат с пробелами:
Заметьте, что в любом случае должен быть пробел между if и открывающей скобкой. Также нужен пробел между закрывающей скобкой и фигурной скобкой (если она есть).
Короткие условия можно записать в одну строку, если это улучшит читабельность. Используйте этот вариант только если строка короткая и условие не содержит секцию else.
Не используйте сокращённый вариант, если есть секция else:
Обычно фигурные скобки не требуются для короткого условия, однако они допустимы. Также сложные условия или код лучше читаются при наличии фигурных скобок. Часто требуют, чтобы любой if был со скобками.
И если одна часть условия использует фигурные скобки, вторую также оформляйте с ними:
Циклы и switch-и
Конструкция switch может использовать скобки для блоков. Описывайте нетривиальные переходы между вариантами. Скобки необязательны для циклов с одним выражением. Пустой цикл должен использовать либо пустое тело в скобках или continue.
Блоки case в switch могут как быть с фигурными скобками, так быть и без них (на ваш выбор). Если же скобки используются, используйте формат, описанный ниже.
Рекомендуется в switch делать секцию default. Это необязательно в случае использования перечисления, да и компилятор может выдать предупреждение если обработаны не все значения. Если секция default не должна выполняться, тогда формируйте это как ошибку. Например:
Переход с одной метки на следующую должен быть помечен макросом ABSL_FALLTHROUGH_INTENDED; (определён в absl/base/macros.h).
Размещайте ABSL_FALLTHROUGH_INTENDED; в точке, где будет переход. Исключение из этого правила — последовательные метки без кода, в этом случае помечать ничего не нужно.
Скобки являются опциональными для циклов с одной операцией.
Пустой цикл должен быть оформлен либо как пара скобок, либо как continue без скобок. Не используйте одиночную точку с запятой.
Указатели и ссылки
Вокруг ‘.’ и ‘->’ не ставьте пробелы. Оператор разыменования или взятия адреса должен быть без пробелов.
Ниже приведены примеры правильного форматирования выражений с указателями и ссылками:
- ‘.’ и ‘->’ используются без пробелов.
- Операторы * или & не отделяются пробелами.
Старайтесь использовать единый стиль в файле кода, при модификации существующего файла применяйте используемое форматирование.
Допускается объявлять несколько переменных одним выражением. Однако не используйте множественное объявление с указателями или ссылками — это может быть неправильно понято.
Логические выражения
Если логическое выражение очень длинное (превышает типовое значение), используйте единый подход к разбивке выражения на строки.
Например, здесь при переносе оператор AND располагается в конце строки:
Отметим, что разбиение кода (согласно примеру) производится так, чтобы && и оператор AND завершали строку. Такой стиль чаще используется с коде Google, хотя расположение операторов в начале строки тоже допустимо. Также, можете добавлять дополнительные скобки для улучшения читабельности. Учтите, что использование операторов в виде пунктуации (такие как && и
) более предпочтительно, что использование операторов в виде слов and и compl.
Возвращаемые значения
Не заключайте простые выражения return в скобки.
Используйте скобки в return expr; только если бы вы использовали их в выражении вида x = expr;.
Инициализация переменных и массивов
Что использовать: =, () или
<> — это ваш выбор.
Вы можете выбирать между вариантами =,
() и <>. Следующие примеры кода корректны:
Будьте внимательны при использовании списка инициализации для типа, у которого есть конструктор с std::initializer_list.
Компилятор предпочтёт использовать конструктор std::initializer_list при наличии списка в фигурных скобках. Заметьте, что пустые фигурные скобки <> — это особый случай и будет вызван конструктор по-умолчанию (если он доступен). Для явного использования конструктора без std::initializer_list применяйте круглые скобки вместо фигурных.
Также конструирование с фигурными скобками запрещает ряд преобразований целых типов (преобразования с уменьшением точности). И можно получить ошибки компиляции.
Директивы препроцессора
Знак # (признак директивы препроцессора) должен быть в начале строки.
Даже если директива препроцессора относится к вложенному коду, директивы пишутся с начала строки.
Форматирование классов
Размещайте секции в следующем порядке: public, protected и private. Отступ — один пробел.
Ниже описан базовый формат для класса (за исключением комментариев, см. описание Комментирование класса):
- Имя базового класса пишется в той же строке, что и имя наследуемого класса (конечно, с учётом ограничения в 80 символов).
- Ключевые слова public:, protected:, и private: должны быть с отступом в 1 пробел.
- Перед каждым из этих ключевых слов должна быть пустая строка (за исключением первого упоминания). Также в маленьких классах пустые строки можно опустить.
- Не добавляйте пустую строку после этих ключевых слов.
- Секция public должна быть первой, за ней protected и в конце секция private.
- См. Порядок объявления для выстраивания деклараций в каждой из этих секций.
Списки инициализации конструктора
Списки инициализации конструктора могут быть как в одну строку, так и на нескольких строках с 4-х пробельным отступом.
Ниже представлены правильные форматы для списков инициализации:
Форматирование пространств имён
Содержимое в пространстве имён пишется без отступа.
Пространство имён не добавляет отступов. Например:
Не делайте отступов в пространстве имён:
При объявлении вложенных пространств имён, размещайте каждое объявление на отдельной строке.
Горизонтальная разбивка
Используйте горизонтальную разбивку в зависимости от ситуации. Никогда не добавляйте пробелы в конец строки.
Общие принципы
Добавление разделительных пробелов может мешать при слиянии кода. Поэтому: Не добавляйте разделительных пробелов в существующий код. Вы можете удалить пробелы, если уже модифицировали эту строку. Или сделайте это отдельной операцией (предпочтительно, чтобы с этим кодом при этом никто не работал).
Циклы и условия
Операторы
Шаблоны и приведение типов
Вертикальная разбивка
Сведите к минимуму вертикальное разбиение.
Это больше принцип, нежели правило: не добавляйте пустых строк без особой надобности. В частности, ставьте не больше 1-2 пустых строк между функциями, не начинайте функцию с пустой строки, не заканчивайте функцию пустой строкой, и старайтесь поменьше использовать пустые строки. Пустая строка в блоке кода должна работать как параграф в романе: визуально разделять две идеи.
Базовый принцип: чем больше кода поместится на одном экране, тем легче его понять и отследить последовательность выполнения. Используйте пустую строку исключительно с целью визуально разделить эту последовательность.
Гайд по оформлению кода на С++ от Стэнфордского университета
Стэнфордский университет представил гайд по основным стандартам оформления кода на С++. Умение корректно оформить ваш код является ценным навыком, так как это в разы облегчает работу других. Также у нас есть подобная статья, посвящённая написанию самодокументируемого кода.
Пробелы и отступы
Отделяйте пробелами фигурные скобки:
Ставьте пробелы между операторами и операндами:
Когда строка становится длиннее 100 символов, разделите её на две, сделав перевод на новую строку после оператора, и продолжайте писать:
Оставляйте пустые линии между функциями и между группами выражений:
Названия и переменные
Давайте переменным описательные имена, такие как firstName или homeworkScore . Избегайте однобуквенных названий вроде x или c , за исключением итераторов вроде i .
Называйте переменные и функции, используя верблюжийРегистр . Называйте классы ПаскальнымРегистром , а константы — в ВЕРХНЕМ_РЕГИСТРЕ . Узнать подробнее про верблюжий регистр вы можете в этой статье.
Если переменная используется лишь внутри определенного if , то делайте её локальной, объявляя в том же блоке кода, а не глобальной.
Выбирайте подходящий тип данных для ваших переменных. Если переменная содержит лишь целые числа, то определяйте её как int , а не double .
Используйте текстовую строку, стандартную для C++, а не С. С++ путает тем, что имеет два вида текстовых строк: класс string из С++ и старый char* (массив символов) из С:
Если определенная константа часто используется в вашем коде, то обозначьте её как const и всегда ссылайтесь на данную константу, а не на её значение:
Никогда не объявляйте изменяемую глобальную переменную. Глобальными переменными должны быть только константы. Вместо того, чтобы делать значение глобальным, сделайте его параметром и возвращайте значение, когда необходимо:
Базовые выражения С++
С++ основан на С, поэтому всегда есть вариант решить задачу «путем С++» и «путем С». Например, когда вы желаете вывести что-либо на системную консоль, вы можете сделать это «путем С++» , использовав оператор вывода cout , в то время как «путем С» вы бы использовали глобальную функцию вроде printf :
Частенько затрудняетесь с выбором между for и while ? Используйте цикл for , когда вы знаете количество повторений, а цикл while , когда количество повторений неизвестно:
Когда используете операторы управления вроде if / else , for , while , всегда используйте < >и соответствующие отступы, даже если тело всего оператора управления состоит лишь из одной строки:
Старайтесь избегать использования выражений break или continue . Используйте их только в том случае, если это абсолютно необходимо.
В C++ есть функция exit , которая немедленно завершает программу. Настоятельно не рекомендуется использовать данную функцию. Программа всегда должна заканчиваться естественно, достигая оператора return функции main .
Используя выражения if / else , подобающе выбирайте между разнообразными if и else шаблонами в зависимости от условий, относящихся к друг другу. Избегайте излишних тестов if :
Если у вас есть выражение if / else , которое возвращает логическое значение, возвращайте результаты теста напрямую:
Никогда не проверяйте значения логического типа, используя == или != с true или false :
Чрезмерность
Если вы используете один и тот же код дважды или более, то найдите способ удалить излишний код, чтобы он не повторялся. К примеру, его можно поместить во вспомогательную функцию. Если повторяемый код похож, но не совсем, то постарайтесь сделать вспомогательную функцию, которая принимает параметры и представляет разнящуюся часть:
Переместите общий код из выражения if / else , чтобы он не повторялся:
Комментарии
Заглавный комментарий. Размещайте заглавный комментарий, который описывает назначение файла, вверху каждого файла. Предположите, что читатель вашего комментария является продвинутым программистом, но не кем-то, кто уже видел ваш код ранее.
Заголовок функции / конструктора. Разместите заголовочный комментарий на каждом конструкторе и функции вашего файла. Заголовок должен описывать поведение и / или цель функции.
Параметры / возврат. Если ваша функцию принимает параметры, то кратко опишите их цель и смысл. Если ваша функция возвращает значение — кратко опишите, что она возвращает.
Исключения. Если ваша функция намеренно выдает какие-то исключения для определенных ошибочных случаев, то это требует упоминания.
Комментарии на одной строке. Если внутри функции имеется секция кода, которая длинна, сложна или непонятна, то кратко опишите её назначение.
TODO. Следует удалить все // TODO комментарии перед тем, как заканчивать и сдавать программу.
Эффективность
Вызывая большую функцию и используя результат несколько раз, сохраните результат в переменной вместо того, чтобы постоянно вызывать данную функцию:
Функции и процедурное проектирование
Хорошо спроектированная функция имеет следующие характеристики:
- Полностью выполняет четко поставленную задачу;
- Не берет на себя слишком много работы;
- Не связана с другими функциями бесцельно;
- Хранит данные максимально сжато;
- Помогает распознать и разделить структуру программы;
- Помогает избавиться от излишков, которые иначе присутствовали бы в программе.
Используйте параметры, чтобы отправлять информацию из функции или когда функции нужно возвратить несколько значений. Не используйте параметры без необходимости. Заметьте, что a , b , и с не являются параметрами в нижеприведенной функции, так как это не нужно:
Когда требуется вернуть значение из функции, используйте значение return :
Отправляя объект в функцию как параметр, вы должны передавать его по ссылке, так как если он будет передан как значение, то будет скопирован весь объект. Копирование объектов требует больших затрат памяти.
Используйте ссылочные переменные, а не указатели. Одна из причин — это то, что ссылочные переменные, в отличие от указателей, не могут принимать значение NULL :
Если вы передаете объект в функцию и код не изменит вида объекта — передайте его как const -ссылку:
Избегайте «цепных» вызовов, когда множество функций вызывают друг друга по цепочке, не возвращая значение в main . Убедитесь, что main является кратким описанием всей программы:
Проектирование классов
Инкапсуляция. Отделяйте ваши объекты, делая все поля данных в вашем классе private :
.h vs .cpp. Всегда размещайте объявления классов и их частей в собственные файлы, ClassName.h . Всегда сворачивайте файлы объявления классов .h в блок препроцессоров #ifndef / define / endif , чтобы избежать множественных объявлений одного класса:
class vs struct. Всегда используйте class , только если вы не создаете очень маленький и простой вид данных, для которого нужны лишь несколько публичных переменных и, возможно, конструктор для их инициализации.
Избегайте ненужных полей. Используйте поля, чтобы хранить важные данные о ваших объектах, но не временные значения, которые используются единожды.