Головоломка «Ханойская башня» и игра «Четыре в ряд» — короткие программы, но так как мы следовали принципам, представленным в книге, их код хорошо читается и прост в отладке. В этих программах применяется ряд полезных практик: они были автоматически отформатированы программой Black, для описания модулей и функций использовались doc-строки, а константы мы разместили в начале файла. Переменные, параметры функций и возвращаемые значения функций ограничиваются одним типом данных, так что аннотации типов (как полезная форма дополнительной документации) оказываются излишними.
В «Ханойской башне» три башни представлены словарем с ключами 'A', 'B' и 'C', значениями которых являются списки целых чисел. Такой подход работает, но если бы программа была сколько-нибудь большой и сложной, для представления этих данных стоило бы воспользоваться классом. Классы и средства ООП в этой главе не использовались, потому что об ООП речь пойдет только в главах 15–17. Просто помните, что для таких структур данных абсолютно нормально использовать класс. Башни выводятся на экран в ASCII-графике, а диски изображаются серией текстовых символов.
Игра «Четыре в ряд» также использует ASCII-графику для вывода представления игрового поля. Изображение поля строится из многострочного текста, хранимого в константе BOARD_TEMPLATE. Строка включает 42 пары фигурных скобок {} для каждой ячейки игрового поля 7 × 6. Строковый метод format() заменяет каждую пару фигурных скобок ячейкой, находящейся в соответствующей позиции. При таком подходе более очевидно, как строка BOARD_TEMPLATE строит игровое поле, выводимое на экран.
Несмотря на различия в структурах данных, у этих двух программ много общего. Обе программы выводят свои структуры данных на экран, запрашивают у игрока входные данные, проверяют ввод, а затем используют его для обновления своих структур данных, прежде чем возвращаться к началу цикла. Однако код для выполнения всех этих действий можно написать многими способами. Как сделать свой код удобочитаемым? Удобочитаемость — субъективное ощущение, а не объективная метрика, определяемая степенью соответствия некоторому набору правил. Исходный код, приведенный в этой главе, показывает, что, хотя к любому коду с запахом всегда стоит присмотреться еще раз, признаки проблемы далеко не всегда указывают на существование проблемы, которую необходимо исправить. Удобочитаемость кода важнее бездумного следования политике недопустимости запахов кода в ваших программах.
Кіру не тіркелу пікір қалдыру үшін