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) Функция печати сообщения по коду ошибки. Программа должна содержать в себе функцию печати сообщения по передаваемому коду ошибки. Вывод сообщения сразу в случае возникновения ошибки делает код менее удобочитаемым.
