Рекомендации по оформлению кода программ.

1) Комментарии.Комментариев в коде должно быть достаточно, чтобы спустя ~полгода можно было по ним вновь разобраться в программе. Обязательно подписывать все циклы и условия как в начале, так и в конце блока кода. Комментарии желательно указывать перед описываемой строкой кода, а не на ней. Оптимальное количество комментариев – один на 3-5 строк кода.

2) Корректные идентификаторы.Как для переменных, так и для функций. Идентификатор должен нести смысловую нагрузку, понятную из названия и не конфликтующую с его содержанием. Для именования идентификаторов используется только чистый английский язык. Крайне нежелательно использовать транслит. В составных идентификаторах каждое слово должно начинаться с заглавной буквы и продолжаться строчными.

3) Оператор goto.Его нет. Совсем. Даже во вложенных циклах.

4) Локализация ресурсов.Все необходимые в программе константы должны быть вынесены в отдельную часть программы (как это сделано в Паскале) и не должны перемешиваться с глобальными или локальными переменными. От использования глобальных переменных стоит избавляться, если это возможно. Исключения: сообщения пользователю, размеры массивов, магические числа для циклов или условий.

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

6) Ориентация на пользователя.Работа пользователя с программой должна быть максимально удобной. Пользователь не должен задаваться вопросом, как выполнить ту или иную функцию в программе или что ему дальше делать – он должен видеть максимально подробные подсказки для возможных действий. Все, что может быть автоматизировано в программе, не должно требовать действий пользователя.

7) Удобство дальнейшей поддержки программы.Код программы должен быть удобным для чтения и внесения в него правок другим человеком. Так как основная стоимость разработки ПО получается на этапе сопровождения программы (после разработки и тестирования), нужно максимально облегчить этот процесс.

8) Выделение отдельных функциональных блоков.Совокупность действий, выполняющих одну задачу, чаще всего должна быть представлена отдельным и обособленным функциональным блоком - функцией. Повторяющиеся более одного раза одинаковые или схожие по типам обрабатываемых значений блоки кода также должны быть представлены функциями. Основная программа (main) должна быть представлена совокупностью функций, в которых также могут вызываться другие функции. Функция, выполняющая одну простую задачу, и которую при этом нельзя разбить на две и больше более простых функций, называется атомарной. Править логику работы программы через подобные атомарные функции проще, чем делать то же самое в коде основной программы.

9) Функциональная независимость, слабая связь между функциональными блоками.Каждая функция должна выполнять свою задачу независимо от того, в какой части программы она находится. Вместо использования функцией глобальных переменных (их использование крайне нежелательно во всей программе), функции должны взаимодействовать друг с другом через свои входные и выходные параметры.

10) Объем функционального блока.Не более одного экрана или одного листа формата А4.

11) Стилистика кода.Код в каждом новом блоке кода обязательно должен отделяться табуляцией от основной части кода (по отношению к данному блоку). Это касается циклов, условий, кода в функциях и т.д. Между логически отделенными блоками кода следует добавлять пустые строки, чтобы визуально их разделять. Положение границ блока кода (begin/end/{} ) – на строке, следующей за объявлением функции, цикла или условия. В выражениях вычисляемые значения должны располагаться в левой части, а константы в правой. Стиль оформления программы должен быть единым на протяжении всего процесса разработки.

12) Разбиение длинных конструкций.Для удобства чтения кода длинные строки и условия следует разбивать и располагать таким образом, чтобы их длина не превышала треть экрана/листа А4.

if ( plane[i].flightNumber[0] != 'Р'

&& plane[i].flightNumber[1] != 'Е'

&& plane[i].flightNumber[2] != 'Й'

&& plane[i].flightNumber[3] != 'С' )

13) Сложность тестирования.Необходимо максимально снижать сложность тестирования программы. Для этого следует искать способы упростить сложные логические конструкции, желательно на стадии проектирования программы.

14) Функция печати сообщения по коду ошибки.Программа должна содержать в себе функцию печати сообщения по передаваемому коду ошибки. Вывод сообщения сразу в случае возникновения ошибки делает код менее удобочитаемым.