Вы абсолютно правы в своем главном наблюдении: никто в здравом уме не назовет класс godObject или функцию spaghettiCode. Это действительно антипаттерны, имена для феноменов в коде, а не для сущностей. И именно в этом, как мне кажется, и заключается самая суть моей гипотезы.
Я пытался сказать не то, что мы так называем переменные, а то, что когнитивный механизм, по которому сообщество дает прозвище уродливому коду (godObject), и механизм, по которому отдельный разработчик ищет удачное имя для переменной (validateEmail), — один и тот же. И там, и там мы пытаемся ухватить суть явления и упаковать ее в яркий, семантически мотивированный знак. godObject — это просто более яркий и гипертрофированный пример этого процесса.
Что касается «очевидных истин». Вы снова правы! Выводы по хорошему именованию не новы — лучшие инженеры приходили к ним интуитивно на протяжении десятилетий. Цель моей работы — не изобрести их заново, а попытаться дать им объяснение и систему через аппарат другой, неожиданной дисциплины. Показать, почему эти «очевидные» истины работают, и почему они так похожи на законы, по которым живет естественный язык.
Надо же!!! аша мысль про «инструментарий, который навязывает стандарт» — это просто в яблочко! Это именно та проблема, над решением которой я сейчас работаю.
Ведь главный вопрос — как создать такой стандарт, который не будет отторгаться командой, а станет ее «второй натурой»? Простые линтеры проверяют синтаксис, но не семантику.
Именно поэтому я сейчас разрабатываю целый междисциплинарный спецкурс для инженеров. Его главная цель — дать команде не программный, а ментальный инструментарий: общий язык и систему понятий (из филологии и риторики), которые позволяют создавать и поддерживать такие стандарты изнутри, на уровне мышления.
Так что спасибо вам огромное — вы идеально сформулировали миссию того, что я пытаюсь сделать!
Браво! Это абсолютно гениальный и стопроцентно точный комментарий. Спасибо вам огромное!
Вы сейчас на практике продемонстрировали главный тезис всей моей статьи. Вы провели безупречный лингвистический анализ имени, разложив его на падежи и части речи, и на основе этого пришли к абсолютно верному инженерному решению. Это и есть лучшее доказательство того, что глубокое, интуитивное чувство языка — ключ к чистому коду.
Вы совершенно правы насчет validateEmail — это действительно более естественный порядок для английского языка (глагол + объект). Мой пример был упрощением, и ваше замечание абсолютно справедливо.
А ваша мысль про EmailValidator.validate() — это уже уровень архитектурного мышления. Вы показали, как контекст(имя класса) берет на себя часть семантической нагрузки, позволяя сделать имя метода еще более лаконичным и точным. Для меня, как для филолога, а не инженера, невероятно ценно видеть, как эти теоретические принципы работают в реальной практике.
Спасибо, что вывели дискуссию на такой невероятный уровень глубины. Именно ради таких комментариев и стоило писать эту статью.
Спасибо вам за такой невероятно глубокий и подробный комментарий! Это именно тот уровень дискуссии, на который я надеялся. Вы затронули несколько абсолютно ключевых моментов, которые заслуживают отдельного обсуждения.
Вы совершенно правы в своем главном тезисе: никто в здравом уме не назовет класс godObject. И здесь вы нащупали самый тонкий момент. Такие имена, как Heisenbug или spaghettiCode, — это не переменные, это прозвища, которые само сообщество дает определенным феноменам в коде. Скорее, я этим хотел показать, что когнитивный механизм, по которому мы даем эти прозвища феноменам, и механизм, по которому мы ищем удачное имя для переменной, — один и тот же. И там, и там мы пытаемся ухватить суть явления и упаковать ее в одно слово.
И ваши практические наблюдения — лучшее тому подтверждение:
«Маленький рабочий набор слов», «хочется короткое слово» — абсолютно! В лингвистике это называется диалектикой принципа экономии усилий и принципа ясности. И поиск идеального имени — это всегда компромисс между этими двумя силами.
«Система наименования... консистентна» (DeviceLocator в devicelocator.xxx) — блестящий пример! По сути, вы описываете создание того, что в лингвистике называется проектным социолектом. Команда договаривается о своем внутреннем «языке», и следование ему — залог выживания.
«...хочется выбрать уместное слово с учётом контекста, а не просто прямой перевод» — вы сейчас сформулировали главную задачу филологии! Работа с уместностью, коннотациями и контекстом — это и есть то, чем филологи занимаются всю жизнь.
И насчет tmp — вы на 100% правы. Для переменной, которая живет три строки, tmp — идеальное имя, потому что ее семантика полностью определяется из сверхблизкого контекста. Проблемы начинаются, когда этот «временный» tmp выживает на протяжении 50 строк и уходит в другую функцию, не так ли? :)
Спасибо еще раз за ваш комментарий. Вы дали мне огромную пищу для размышлений и, по сути, идеально дополнили статью с точки зрения практикующего инженера.
Спасибо за такой развернутый и вдумчивый комментарий! Вы абсолютно правы в главном: ключ к успеху — это «описанный стандарт, принятый в команде». Моё исследование как раз и является попыткой заглянуть «под капот» такого стандарта и понять, на каких фундаментальных, почти интуитивных принципах он строится.
И ваши правила — блестящий тому пример. Смотрите:
«Называть так, чтобы можно было понять в текущем контексте» — это же и есть требование к созданию семантически прозрачного знака.
А ваша формула «"что" + "делает"» (emailValidate) — это классический пример того, что филологи называют именем с ясной «внутренней формой».
Возможно, я был слишком провокационен в заголовке :) Моя цель — не сказать, что код это гуманитарная дисциплина, а показать, что инструменты гуманитарных наук могут быть невероятно полезны для решения наших с вами инженерных задач. Ведь, по сути, любой стандарт, о котором вы пишете, — это и есть тот самый язык, на котором команда договаривается общаться.
Спасибо еще раз, что поделились своей системой. Очень интересно, это результат вашей личной практики или вы пришли к нему вместе с командой?
Идеальный комментарий, спасибо! Вы привели вторую половину уравнения, которое я пытался решить в статье. Все знают, что именование — это сложно. Но ПОЧЕМУ?
Мне кажется, ответ как раз в том, что программисты пытаются решить лингвистическую проблему инженерными методами. А это как пытаться отладить сонет с помощью дебаггера.
Моя статья — это, по сути, попытка применить филологический инструментарий к этой «второй самой сложной вещи».
благодарю вас за глубокую и крайне своевременную статью. Ваши размышления о первичности субъективного и условности «объективного» как интерсубъективного соглашения находят поразительную и, на первый взгляд, неожиданную параллель в области, которую я исследую — в семиотике программного кода.
Вы пишете о том, как субъект «оформляет» непознаваемые «квази-процессы» в виде условных, конечных форм. В программировании мы наблюдаем этот процесс в чистом, почти лабораторном виде. Один и тот же фрагмент кода существует одновременно в двух мирах:
В «ноуменальном мире» машины. Для процессора код — это абсолютно детерминированный поток инструкций, операций с ячейками памяти. Это тот самый мир «сам по себе», где нет ни «пользователя», ни «заказа», а есть лишь 0x7FFF и 0xFFFF.
В «феноменальном мире» человека. Для разработчика тот же самый код — это мир осмысленных сущностей: userAccount, databaseConnection. Мы, как субъекты-программисты, «оформляем» безличные машинные операции в виде понятных нам концептов.
И самое интересное — это рождение «объективности». То, что в IT-индустрии называют «стандартами кодирования» или «чистым кодом», — это и есть та самая «объективность», рожденная из интерсубъективного соглашения. Сообщество разработчиков (множество субъектов) договаривается, что определенные формы именования и структурирования являются «объективно» хорошими, потому что они понятны большинству. Субъективное (удобство чтения для меня) становится «объективным» (стандартом для команды).
В связи с этим возникает вопрос: не кажется ли вам, что программосфера (мой авторский термин) — вся совокупность кода и коммуникации вокруг него — представляет собой уникальную искусственную среду, где мы можем в режиме реального времени наблюдать те самые процессы рождения «субъективного» и «объективного», о которых Кант мог размышлять лишь умозрительно?
С уважением, Артем Лакомов, филолог, исследователь семасиологии программного кода.
Вы абсолютно правы в своем главном наблюдении: никто в здравом уме не назовет класс
godObjectили функциюspaghettiCode. Это действительно антипаттерны, имена для феноменов в коде, а не для сущностей. И именно в этом, как мне кажется, и заключается самая суть моей гипотезы.Я пытался сказать не то, что мы так называем переменные, а то, что когнитивный механизм, по которому сообщество дает прозвище уродливому коду (
godObject), и механизм, по которому отдельный разработчик ищет удачное имя для переменной (validateEmail), — один и тот же. И там, и там мы пытаемся ухватить суть явления и упаковать ее в яркий, семантически мотивированный знак.godObject— это просто более яркий и гипертрофированный пример этого процесса.Что касается «очевидных истин». Вы снова правы! Выводы по хорошему именованию не новы — лучшие инженеры приходили к ним интуитивно на протяжении десятилетий. Цель моей работы — не изобрести их заново, а попытаться дать им объяснение и систему через аппарат другой, неожиданной дисциплины. Показать, почему эти «очевидные» истины работают, и почему они так похожи на законы, по которым живет естественный язык.
Надо же!!! аша мысль про «инструментарий, который навязывает стандарт» — это просто в яблочко! Это именно та проблема, над решением которой я сейчас работаю.
Ведь главный вопрос — как создать такой стандарт, который не будет отторгаться командой, а станет ее «второй натурой»? Простые линтеры проверяют синтаксис, но не семантику.
Именно поэтому я сейчас разрабатываю целый междисциплинарный спецкурс для инженеров. Его главная цель — дать команде не программный, а ментальный инструментарий: общий язык и систему понятий (из филологии и риторики), которые позволяют создавать и поддерживать такие стандарты изнутри, на уровне мышления.
Так что спасибо вам огромное — вы идеально сформулировали миссию того, что я пытаюсь сделать!
Браво! Это абсолютно гениальный и стопроцентно точный комментарий. Спасибо вам огромное!
Вы сейчас на практике продемонстрировали главный тезис всей моей статьи. Вы провели безупречный лингвистический анализ имени, разложив его на падежи и части речи, и на основе этого пришли к абсолютно верному инженерному решению. Это и есть лучшее доказательство того, что глубокое, интуитивное чувство языка — ключ к чистому коду.
Вы совершенно правы насчет
validateEmail— это действительно более естественный порядок для английского языка (глагол + объект). Мой пример был упрощением, и ваше замечание абсолютно справедливо.А ваша мысль про
EmailValidator.validate()— это уже уровень архитектурного мышления. Вы показали, как контекст(имя класса) берет на себя часть семантической нагрузки, позволяя сделать имя метода еще более лаконичным и точным. Для меня, как для филолога, а не инженера, невероятно ценно видеть, как эти теоретические принципы работают в реальной практике.Спасибо, что вывели дискуссию на такой невероятный уровень глубины. Именно ради таких комментариев и стоило писать эту статью.
Спасибо вам за такой невероятно глубокий и подробный комментарий! Это именно тот уровень дискуссии, на который я надеялся. Вы затронули несколько абсолютно ключевых моментов, которые заслуживают отдельного обсуждения.
Вы совершенно правы в своем главном тезисе: никто в здравом уме не назовет класс
godObject. И здесь вы нащупали самый тонкий момент. Такие имена, какHeisenbugилиspaghettiCode, — это не переменные, это прозвища, которые само сообщество дает определенным феноменам в коде. Скорее, я этим хотел показать, что когнитивный механизм, по которому мы даем эти прозвища феноменам, и механизм, по которому мы ищем удачное имя для переменной, — один и тот же. И там, и там мы пытаемся ухватить суть явления и упаковать ее в одно слово.И ваши практические наблюдения — лучшее тому подтверждение:
«Маленький рабочий набор слов», «хочется короткое слово» — абсолютно! В лингвистике это называется диалектикой принципа экономии усилий и принципа ясности. И поиск идеального имени — это всегда компромисс между этими двумя силами.
«Система наименования... консистентна» (
DeviceLocatorвdevicelocator.xxx) — блестящий пример! По сути, вы описываете создание того, что в лингвистике называется проектным социолектом. Команда договаривается о своем внутреннем «языке», и следование ему — залог выживания.«...хочется выбрать уместное слово с учётом контекста, а не просто прямой перевод» — вы сейчас сформулировали главную задачу филологии! Работа с уместностью, коннотациями и контекстом — это и есть то, чем филологи занимаются всю жизнь.
И насчет
tmp— вы на 100% правы. Для переменной, которая живет три строки,tmp— идеальное имя, потому что ее семантика полностью определяется из сверхблизкого контекста. Проблемы начинаются, когда этот «временный»tmpвыживает на протяжении 50 строк и уходит в другую функцию, не так ли? :)Спасибо еще раз за ваш комментарий. Вы дали мне огромную пищу для размышлений и, по сути, идеально дополнили статью с точки зрения практикующего инженера.
Спасибо за такой развернутый и вдумчивый комментарий! Вы абсолютно правы в главном: ключ к успеху — это «описанный стандарт, принятый в команде». Моё исследование как раз и является попыткой заглянуть «под капот» такого стандарта и понять, на каких фундаментальных, почти интуитивных принципах он строится.
И ваши правила — блестящий тому пример. Смотрите:
«Называть так, чтобы можно было понять в текущем контексте» — это же и есть требование к созданию семантически прозрачного знака.
А ваша формула «"что" + "делает"» (
emailValidate) — это классический пример того, что филологи называют именем с ясной «внутренней формой».Возможно, я был слишком провокационен в заголовке :) Моя цель — не сказать, что код это гуманитарная дисциплина, а показать, что инструменты гуманитарных наук могут быть невероятно полезны для решения наших с вами инженерных задач. Ведь, по сути, любой стандарт, о котором вы пишете, — это и есть тот самый язык, на котором команда договаривается общаться.
Спасибо еще раз, что поделились своей системой. Очень интересно, это результат вашей личной практики или вы пришли к нему вместе с командой?
Идеальный комментарий, спасибо! Вы привели вторую половину уравнения, которое я пытался решить в статье. Все знают, что именование — это сложно. Но ПОЧЕМУ?
Мне кажется, ответ как раз в том, что программисты пытаются решить лингвистическую проблему инженерными методами. А это как пытаться отладить сонет с помощью дебаггера.
Моя статья — это, по сути, попытка применить филологический инструментарий к этой «второй самой сложной вещи».
Уважаемый Александр,
благодарю вас за глубокую и крайне своевременную статью. Ваши размышления о первичности субъективного и условности «объективного» как интерсубъективного соглашения находят поразительную и, на первый взгляд, неожиданную параллель в области, которую я исследую — в семиотике программного кода.
Вы пишете о том, как субъект «оформляет» непознаваемые «квази-процессы» в виде условных, конечных форм. В программировании мы наблюдаем этот процесс в чистом, почти лабораторном виде. Один и тот же фрагмент кода существует одновременно в двух мирах:
В «ноуменальном мире» машины. Для процессора код — это абсолютно детерминированный поток инструкций, операций с ячейками памяти. Это тот самый мир «сам по себе», где нет ни «пользователя», ни «заказа», а есть лишь
0x7FFFи0xFFFF.В «феноменальном мире» человека. Для разработчика тот же самый код — это мир осмысленных сущностей:
userAccount,databaseConnection. Мы, как субъекты-программисты, «оформляем» безличные машинные операции в виде понятных нам концептов.И самое интересное — это рождение «объективности». То, что в IT-индустрии называют «стандартами кодирования» или «чистым кодом», — это и есть та самая «объективность», рожденная из интерсубъективного соглашения. Сообщество разработчиков (множество субъектов) договаривается, что определенные формы именования и структурирования являются «объективно» хорошими, потому что они понятны большинству. Субъективное (удобство чтения для меня) становится «объективным» (стандартом для команды).
В связи с этим возникает вопрос: не кажется ли вам, что программосфера (мой авторский термин) — вся совокупность кода и коммуникации вокруг него — представляет собой уникальную искусственную среду, где мы можем в режиме реального времени наблюдать те самые процессы рождения «субъективного» и «объективного», о которых Кант мог размышлять лишь умозрительно?
С уважением, Артем Лакомов, филолог, исследователь семасиологии программного кода.