Исследование недоразумений и способов их устранения
В главе Выбор имен из Философии дизайна программного обеспечения [2] Джон Остерхаут дает действительно полезные советы о том, как выбирать имена для различные элементы, составляющие наше программное обеспечение, такие как переменные, функции, классы и т. д.
Но есть один совет, с которым у меня проблемы. Он пишет о том, как учитывать конкретное имя переменной или метода в нашем коде:
«Если кто-то видит это имя изолированно, не видя его декларации, документации или кода, использующего это имя, насколько точно они смогут догадаться, к чему это имя относится? Есть ли какое-нибудь другое название, которое прорисовывает более ясную картину? »
С лингвистической точки зрения я не уверен, как это сработает. Одним из аспектов слов является то, что они имеют значение в контексте, не только в предложении, в котором они произносятся, но и в социокультурной среде, окружающей высказывание.
В 1936 году И. А. Ричардс прочитал цикл лекций на тему Философия риторики [3], где вместо того, чтобы заниматься дискурсом и конфликтом, его интересовали изучение недопонимания и способы его устранения. Там он представляет набор идей, которые действительно полезны, когда дело доходит до размышлений о том, как назвать вещи в программных проектах.
Давайте посмотрим, что И. А. Ричардс говорит о значении слов:
Основная причина непонимания […] - суеверие с правильным смыслом.
Это суеверие, по его словам, заставляет нас думать, будто мы думаем так:
[…] Слово имеет собственное значение (в идеале, только одно), не зависящее от его использования и цели, для которой оно должно быть произнесено, и контролирующее его использование. […] Стабильность значения слова проистекает из постоянства контекстов, придающих ему значение.
Так что все дело в контексте. Что-то такое простое, как user.getRole()
, будет иметь другое значение, если пользователь является пользователем подключения к базе данных или пользователем такой службы, как Twitter.
Эта проблема хорошо известна и в лингвистике, в книге Language The Unknown [1] Кристева говорит:
Значение слова [a] никогда не может быть полным, если оно не изучено в дискурсе, принимая во внимание произнесение говорящего субъекта.
Функция расстояния
Итак, что мы можем сделать с проблемой именования в программировании?
В этой главе Оустерхаут высказывает иное мнение, нежели его, - мнение сообщества Go, которое предпочитает короткие имена переменных. Он цитирует слова Эндрю Геррана:
длинные имена скрывают, что делает код
Затем он сравнивает этот код в стиле Геррана:
По сравнению с кодом Оустерхаута, в котором используются более длинные имена переменных:
Я утверждаю, что индексные переменные хорошо известны в литературе по программированию, поэтому их вызов i
или index
не сильно повлияет на удобочитаемость вашего кода. Теперь я с Оустерхаутом, когда он говорит, что переменная count
дает лучшее представление о замысле кода. Тем не менее, мне было бы интересно услышать приведенную выше цитату Геррана в контексте, чтобы лучше понять, что он имеет в виду, когда говорит, что длинные имена скрывают то, что делает код.
Тем не менее Оустерхаут завершает главу замечательной цитатой Геррана:
«Чем больше расстояние между объявлением имени и его использованием, тем длиннее должно быть имя».
Опять же, все дело в контексте.
Значение: выросшее растение
Давайте закончим эту статью цитатой Ричардса о том, как нам следует думать о значении.
Нам лучше думать о значении, как если бы это было выросшее растение, а не наполненная банка или вылепленный кусок глины.
Это представляет собой порождающую метафору - выросшее растение - которую мы можем использовать, когда изучаем эволюцию наших собственных программных проектов, чтобы понять, как значение наших функций меняется по мере того, как проект претерпевает различные изменения *.
Примечания:
* Подумайте, например, как в RabbitMQ exchange:route(exchange, msg, routes)
изначально использовался для маршрутизации сообщений в очереди, но со временем он также закончил маршрутизацию сообщений от обменов к обменам.
Использованная литература:
- Кристева, Юлия. Неизвестный язык, начало в лингвистике. Издательство Колумбийского университета, 1981.
- Остерхаут, Джон. Философия дизайна программного обеспечения. Якнян Пресс, 2018
- Ричардс, Айвор Армстронг. Философия риторики. Издательство Оксфордского университета, 1965.
Кредиты:
Изображение из онлайн-архива Британской библиотеки, из Цапля Александрийская, Pneumatica, De automatis.