Репетитор о важности содержательного именования в программах
По сути, программа это план действий, которые должен исполнить компьютер. Люди тоже создают себе подобные «программы». Рассмотрим близкий нам пример и легкий для объяснений репетитора — два плана утреннего распорядка школьника:
1. Вечером завести будильник на 7:30. Если утром проспал, быстро встать, одеться как обычно, взять портфель, запереть дверь и бежать в школу.
Иначе встать с постели, умыться и почистить зубы, позавтракать. Посмотреть на термометр за окном, одеться по погоде, взять зонт если идёт дождь. Взять портфель, запереть дверь и идти в школу.
2. Буд. 7:30. Зав.+ч.зуб., зап. дв., и з. если д. Ид. в ш., бегом если пр-л.
Нетрудно понять, какой план лучше. Но школьные учебники ненавязчиво приучают писать программы в духе второго варианта. Разберёмся, какие неприятности это приносит и как их избежать. По сей день живёт и здравствует пережиток эпохи примитивных компьютеров — стремление сокращать имена переменных и функций. Как будто чем короче, тем удобнее. Условились, что некий X обозначает одно, F — другое, а дальше считаем, что это впечатано в мозг и не вызовет затруднений. И никто не будет путаться, даже если одни и те же буквы используем в разных программах, вкладывая в них различный смысл.
Вдобавок, многие упражнения в учебниках это реализация математических расчётов, например площади треугольника по формуле S = 0.5ah. В таких случаях выбор примитивных имён переменных a, h, S даже выглядит логичным. В итоге формируется вредная привычка, а важнейший аспект программирования остаётся без внимания. Компьютеру без разницы, как именуются переменные, но человек не машина. Если приходится держать в голове что-то лишнее, или отвлекаться на припоминание, то внимание неизбежно рассеивается. Значит, программа получится хуже, ошибок будет больше, как и потраченного на их исправление времени.
Имена сущностей должны помогать обдумывать алгоритм, а не создавать дополнительные сложности. Прежде, чем программа будет готова, придётся много раз побыть в роли компьютера: читая код, мысленно исполнять команды и одновременно следить со стороны — всё ли «работает» по плану. Это сложно и требует предельной концентрации внимания, так что нужно максимально облегчить себе работу.
Мы привыкли думать на человеческом языке, к нему и нужно стремиться при написании программы. Главное — точность формулировок, однозначность смысла и естественность выражений. При таком подходе «корявые» места сами будут бросаться в глаза. И тогда мы переделаем запутанное выражение, или заметим ошибку ещё до запуска программы.
Может показаться, что от длинных имен больше путаницы, чем от коротких — так много букв, читать устанешь! Зато не придётся каждый раз вспоминать, что же обозначает некое число или очередная безликая переменная. Т.к. программа перечитывается и исправляется много раз, избыточность текста с лихвой перекрывает издержки. В профессиональной среде это общепризнанный стандарт, почему-то он до сих пор не добрался до школьных учебников.
Для иллюстрации возьмём две простейшие программы из учебника информатики и улучшим их так, чтобы сделать текст более понятным. Попробуйте прочитать обе версии вслух и сравнить, какая легче укладывается в голове. Первая программа должна выполнить деление с остатком. Попытайтесь разобраться, как она работает. Оцените, сколько раз приходится напрячься, чтобы не запутаться в именах переменных. Как по заказу, авторы учебника допустили ошибку, являющуюся типичным следствием неудачного выбора имён! Попробуйте её обнаружить без помощи репетитора:
Ошибка здесь такая: в заголовке цикла остаток сравнивается с делимым вместо делителя, и после первой же итерации цикл завершится. Чтобы обнаружить ошибку, нужно помнить, что есть x, что есть y и что такое r. А также заметить, что вместо y стоит x, это неверно. Обычно глаза пропускают такие мелочи, тем более, когда программист — новичок.
Теперь разберём улучшенную версию репетитора:
Кроме того, что теперь легко избежать сделанную в первом варианте ошибку, есть и другие плюсы. Гораздо труднее будет записать введённое пользователем число не в ту переменную, или вывести на экран не то, что нужно.
Например, последние две команды вывода очень похожи. Поэтому при наборе программы многие скопируют первую строку, а затем исправят слово «частное» на «остаток». В этом месте легко поспешить и сделать ошибку: кто-нибудь обязательно забудет изменить и имя переменной. Но запись writeln ( 'Остаток = ', chastnoe) режет глаз, а writeln ( 'Остаток q=', q) — нет. Значит, в «улучшенном» варианте заметить ошибку гораздо легче.
Следующая программа должна решать задачу про спортсмена, который приступает к тренировкам по графику: в первый день он должен пробежать 10 км; каждый следующий день увеличивать дистанцию на 10% от нормы предыдущего дня. Как только дневная норма достигнет или превысит 25 км, необходимо прекратить её увеличение и далее пробегать ежедневно по 25 км. Начиная с какого дня спортсмен будет пробегать по 25 км?
И снова эти бессмысленные i и x! Почему бы не использовать слова, которые отражают содержание задачи?
Напишем улучшенную версию. В идеале, числа 0.1, 10 и 25 выносятся в именованные константы, но сейчас обойдёмся без фанатизма:
Не надо бояться того, что программа стала более объёмной. Современные редакторы предоставляют уйму средств, которые облегчают работу с текстом. Взамен мы получаем значительные преимущества, особенно заметные при написании более сложных программ.
Формат статьи не позволяет подробнее разобрать все плюсы и нюансы данного подхода, и тем более отработать его наилучшим образом. Это и многое другое можно сделать на индивидуальных занятиях с репетитором, приходите.
Петровский Александр, репетитор по математике и информатике. Москва. Строгино.
