Как разработчик, я считаю, что придумывать лучшее название для чего-то — это деятельность, которой я придаю особое значение.
Как я упоминал в предыдущей статье, я рассматриваю программирование скорее как строительство мира. Подобно писателю-фантасту, создающему вымышленный мир для своих читателей.
Точно так же, как писатель-фантаст тратит время на то, чтобы называть людей, места и вещи в своем мире, я провожу время, называя переменные, функции и модули.
Как человек, который десятилетиями «давал названия вещам», я могу с уверенностью сказать, что эта критическая задача никогда не становится легче.
На самом деле, со временем это становится сложнее по мере увеличения глубины моих знаний и диапазона. Это было проще, когда я был маленьким программистом, и мой «словарь» был более ограниченным.
Это прозвучит глупо: я дошел до того, что уважаю названия вещей до такой степени, что часто не осмеливаюсь называть некоторые вещи.
Например, я обнаружил, что хочу писать код, похожий на этот
const uppercase = (value) => value.toUpperCase(); ["red", "green", "blue"].map(uppercase);
против этого:
const uppercase = (value) => value.toUpperCase(); ["red", "green", "blue"].map((color) => uppercase(color));
(удаляет лишнее имя color)
Я часто редактирую код с «дополнительными именами», чтобы сделать его более кратким. Почти никогда не наоборот.
Преимущество заключается в том, что этот код стал более гибким и может использоваться во многих других контекстах.
["small", "medium", "large"].map((color) => uppercase(color)); ["small", "medium", "large"].map(uppercase);
Обратите внимание, что название color вместо того, чтобы освещать происходящее и заполнять историю, делает прямо противоположное и вносит путаницу, возможно, даже ложь. Более сжатая безымянная версия в каком-то смысле «лучше».
Конечно, та же проблема существует с любым именем
const uppercase = (value) => value.toLowerCase(); ["red", "green", "blue"].map(uppercase);
Когда я что-то называю, я должен быть очень осторожным, чтобы имя согласовывалось с тем, что читатель думал, что это имя означает .
Проблема заключается в этом соглашении между читателем и писателем. Проблемы возникают даже тогда, когда читатель и писатель один и тот же человек (возможно, до и после обеда), а тем более, если другие люди в командной среде или случайный пользователь в Интернете должны прийти к соглашению.
Было бы неплохо вообще избавиться от имён.
К сожалению, это делает код таким же нечитаемым, как писатель-фантаст, пишущий рассказ без имен персонажей, мест, вещей и т. д. Возможно, это выполнимо, но я сомневаюсь, что читателю понравится этот опыт.
Человеческий разум ограничен, и ему нужны имена, чтобы понять мир.
Именование сложно
Печальный факт заключается в том, что имена являются сложной частью программирования и требуют постоянной заботы и внимания. В балансе они также являются источником большей части смысла и радости.
При наименовании это в определенной степени зависит от того, кто является целевой аудиторией и что, по их мнению, означает или представляет имя.
Когда я говорю foo в паре с bar, эти имена представляют что-то конкретное для одной аудитории и могут быть бессмысленными для другой.
Когда я говорю map, это становится сложнее, потому что это слово имеет много значений в множестве контекстов для многих аудиторий.
Однако, если я могу уйти без использования какого-либо имени, это элегантное решение, которое подходит почти везде.
Стандартные имена почти невидимы
Я рекомендую широко читать и исследовать как можно больше кода. Если имя всплывает неоднократно, я делаю все возможное, чтобы обратить на это внимание, особенно на то, как оно неявно определяется через использование.
Таким образом, со временем создается словарный запас, позволяющий говорить с другими программистами на языке, понятном для программистов.
Это помогает использовать «стандартное» имя для чего-либо, снимая нагрузку как с автора, так и с читателя.
Цикл for, не использующий i в качестве счетчика, был бы сложнее для большинства читателей, использующих си-подобный язык 20-го века, для чтения.
Я считаю, что стандартные имена лучше, чем «безымянные».
Вывод
Я не верю, что есть какой-то «правильный» ответ на вопрос, когда и как называть вещи. Подобно тому, как нет «правильного» ответа на то, как любой автор рассказа должен называть вещи в своем мире.
«Не называть» — ценный инструмент в наборе инструментов для именования.
Я отмечаю, что неназывание — это уловка, которую используют многие строители мира в письменной форме.
Часто я нахожу истории с меньшим количеством названий, за которыми нужно следить, и они имеют больше вневременного качества. Истории с более именами, которые я считаю, имеют более непосредственное и настоящее качество.
Думаю, то же самое относится и к именованию в программировании. В той мере, в какой программа должна быть вневременной, требуется меньше имен. В зависимости от того, является ли программа разовой, индивидуальной или хочет заполнить определенную немедленную роль, требуются дополнительные имена.
Имея это в виду, я думаю, что лучше ошибиться в сторону слишком большого имени, а затем уменьшить имена по мере изменения кода с течением времени. Я также нахожу это естественной склонностью, и поэтому ее легче достичь и оставаться в соответствии с ней. Имена, пережившие множество «выбраковок», со временем, как я обнаружил, обретают более глубокий смысл и назначение и, таким образом, окупаются.
Первоначально опубликовано на https://github.com.
