Основи програмування на С ++ для початківців

Форматування вихідного коду

стандарт форматування коду, Угода про кодування в С ++Правильное форматирование кода действительно важно, если хотите чтобы код был легко-читаемым и был понятен не только вам. К примеру, студенты одной группы, которые читают одинаковую литературу по программированию, которым программирование преподает один и тот же человек, всё равно решают задачи разными способами. При этом у каждого свой особый стиль форматирования кода.

Если вы когда-либо пытались читать чужой код, то замечали, что необходимо некоторое время, чтобы перестроиться и начать понимать, как работает этот код и что он реализует. Конечно, писать код можно по-разному, в том числе не совсем читабельно, и что самое интересное, программа будет замечательно работать. Вот посмотрите на этот код:

Он полностью рабочий и никаких проблем при его выполнении не происходит. Но искренне жаль того программиста, которому «в наследство» достанется программа, написанная таким образом, и которому надо будет в эту программу что-то добавить или усовершенствовать её. Это еще хорошо, что в данной программе переменным даны осмысленные имена, а не int a, int b. Хотя программа очень простая, она очень плохо читается. Другое дело если она будет написана с использованием правил стандартов форматирования кода и соглашений о кодировании – с пробелами, отступами, переносами строк, комментариями:

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

Практически всегда, над созданием одной программы работают несколько программистов. При этом сопровождать программу в дальнейшем может уже другая группа программистов. Становится очевидной необходимость создания единого стандарта кодирования. Якщо програмісти будуть дотримуватися цих стандартів при написанні коду - у всіх він буде виглядати однаково, що в рази полегшить роботу над колективними проектами. Зачастую контора сама вырабатывает свой собственный стандарт кодирования (coding convention), но есть распространенные стандарты. К ним относятся, например:

Google C Style Guide

Coding Standards IBM

Linux kernel coding style

Повна версія угоди про кодування на мові С ++ англійською тут.

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

Поговорим о содержании стандартов и соглашений.

Основными задачами всех стандартов и соглашений о кодировании является способствование:

-написанию легко-читаемого кода, понятного для всех;

-написанию безопасного кода (ведь эти стандарты были созданы программистами-практиками, которые знают, какие ошибки может повлечь за собой неправильное оформление кода);

-единообразного кода (у всех структура кода выглядит схоже).

Просмотрев несколько стандартов и соглашений, можно увидеть, что в основном внимание уделяется следующим пунктам:

имена переменных, констант, функций, классов

Главное при объявлении переменной (функции, класса и т.д.) – дать осмысленное имя, как можно ближе к контексту использования. Допустим, в вашей программе определено больше 20-ти переменных, и всем дано имя в виде буквы алфавита. Согласитесь, даже вам, создателю этой программы, будет тяжело работать с этими переменными. Не говоря уже о том, что нужно так же помнить какие данные хранит каждая из них. Гораздо легче работать с переменными, имеющими обоснованные имена:

age – возраст;
number – номер;
amount – количество;
name – имя.

Желательно имена писать не английским транслитом, а английскими словами.

не vozrast – а age;
не kolichestvo – а amount.

Если вы не знаете перевода, воспользуйтесь одним из множества онлайн переводчиков. Заодно поповните ваш словниковий запас. Правила, згідно з якими даються імена змінним, можна почитати в нашій статті Типи даних, змінні та константи у С++.

Константам рекомендується присвоювати імена або складаються з літер верхнього регістру (HOURS_IN_DAY, SIZE) либо каждое новое слово с большой буквы, как Google C Style Guide (kHoursInDay). Говоря о константах, их советуют использовать везде, где только можно. Не объявляйте переменные хранящие количество дней в неделе и месяцы в году – объявляйте константные переменные в таких случаях. Относительно функций – если функция не изменяет аргумент, передаваемый по ссылке или по указателю, то аргумент должен быть константой.

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

printData(); – печать данных
enterName(); – ввод имени
showStr(); – показать строку

В имени класса первая буква должна быть заглавной:

class Employee
class Point

Если имя состоит из нескольких слов, написать его можно разными способами.

– каждое новое слово с большой буквы (верблюжий регистр): boxWithApple, amountBoxesForSale

– использовать нижний прочерк между словами: box_with_apple, amount_boxes_for_sale

Не бойтесь давать сложные имена. У середовищі Microsoft Visual Studio обращаясь, к объявленной переменной (начиная вводить ее имя), вам будет предложено выбрать имя из выпадающего списка. Давати занадто довгі імена теж не варто. Цілком реально відобразити суть змінної в декількох словах.

Сразу хочу рассказать о «венгерской нотации» – соглашении об именовании переменных и других идентификаторов в коде программ. Суть «венгерской нотации» в том, что имя переменной (функции, массива и т.д.), начинается с префикса, состоящего из одной или нескольких букв. Приведу несколько примеров объявления имен идентификаторов с префиксами:

int iAmount или nAmount,

bool bChoice,

int aNumbers (a говорит о том, что aNumbers – это массив),

string sName (рядок),

int* pArr (от слова pointer – указатель)

Когда мы встретим такое имя в коде, то его префикс будет говорить нам о том, что это за идентификатор и какие данные он хранит.

фигурные скобки

У деяких угодах і стандартах рекомендовано використовувати фігурні дужки в блоках if, else, while, do, for даже если они содержат всего одну строку либо не содержат ничего. Наприклад:

Каждую фигурную скобку желательно располагать в отдельной строке. Так очень легко проследить, где блок начинается и где заканчивается.

пробелы в строке и отступы между строками

Рекомендуется не использовать пробелы в конце строки перед оператором точка с запятой.

При использовании оператора присвоения значения пробелы необходимы с обоих сторон от этого оператора:

Это же касается и операторов используемых в арифметических выражениях:

Застосовуючи унарні оператори, пробелы не нужны:

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

і так без неї:

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

комментирование кода

К сожалению, многие не любят комментировать код, хоча коментарі грають важливу роль в підтримці читання коду на високому рівні. Как написано в Google C Style Guide «Комментарии важны, но лучше когда код сам говорит за себя. Давать осмысленные имена переменным гораздо лучше, чем давать непонятные названия и затем раскрывать их суть в комментариях»

Оставлять комментарии в коде можно либо используя двойной слэш // (комментирование одной строки), либо /* комментарий */ . Вторым способом можно оформить многострочный комментарий. Але перевагу автори деяких стандартів пропонують віддавати все ж коментування з використанням подвійного слеша // .

Каждая функция должна иметь комментарии непосредственно перед ней, которые описывают то, что делает эта функция и как её использовать. Наприклад, перед функцией можно написать: // Открывает файл, или // печатает данные

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

В стандартах форматирования кода можно почерпнуть еще много чего полезного для формирования собственного хорошего стиля программирования. Всего в данной статье не перечислишь. Поэтому постарайтесь найти время и почитать некоторые первоисточники, посилання на які були наведені вище в статті. Рекомендую також почитати про систему документування вихідних текстів Doxygen.

Хочу обрадовать тех, кому все же придется столкнуться с кодом, написанным подобно первому листингу в этой статье. У середовищі розробки Microsoft Visual Studio 2013 Express (возможно, и в более ранних версиях) есть “спасательная комбинация клавиш” Ctrl K затем Ctrl F, нажав которую осуществится форматирование выделенного исходного кода. То есть если выделить неотформатированный код и нажать эту комбинацию клавиш – автоматически добавятся и необходимые пробелы, и отступы, и скобки перенесутся в отдельные строки. В общем станет код выглядеть, как для людей.

Применяя на практике форматирование кода, описанное в стандартах и соглашениях о кодировании, вы добьетесь и достойной легкой читаемости кода, и его безопасности. Этим вы облегчите работу и себе и коллегам по проекту. Возможно, даже кто-то скажет вам спасибо. А я говорю спасибо моему знакомому – автору “Блога программиста” pro-prof.com за то, что предложил и помог мне написать статью на данную тему.

4 думки про "Форматування вихідного коду

залишити коментар

Ваша електронна адреса не буде опублікований. Обов'язкові поля позначені * *