Именование переменных — это философия. Это предложение не просто восприятие, не просто отбрасывание всего сложного, необъяснимого на философию.

Это философия в истинном смысле, философия с философскими навыками и практическим руководством.

Выполнение программы на машине не требует использования имен переменных, а выполнение программы в человеческом мозгу требует использования имен переменных.

Человеческий мозг выполняет программу и следует когнитивным законам психологии, поэтому он не совсем совпадает с характеристиками машинного выполнения программы.

Одна и та же задача может быть решена разными языками программирования, а также может быть решена по-разному в одном и том же языке программирования. Это отношение один ко многим.

Однако существует очень мало реализаций кода, которые следуют законам человеческого познания и, таким образом, ведут себя как - более читабельные.

Конечно, когнитивный закон здесь представляет собой трехмерную модель, а не одностороннюю:

• Хороший код — это код, который вы можете прочитать без обучения и без вашего мозга;

• Я думаю, что его легко читать, и благодаря эмпатии я представляю, что код, который легко читается людьми, которые не так хороши, как я, — это код, соответствующий законам познания.

Люди хорошо учатся, и само обучение может быть интересным процессом. Обучение дизайну кода и поощрение других к обучению — это осуществимая стратегия, позволяющая более полно использовать законы познания.

Таким образом, код, который на первый взгляд не прост для понимания, не обязательно является кодом, который не читается.После изучения код, который нелегко понять, может стать очень интуитивным кодом и очень элегантным кодом. Этот опыт обучения является обычным явлением в математических формулах, где код по существу представляет собой более тривиальные математические формулы.

Итак, какие когнитивные законы человека могут помочь нам улучшить выразительность кода? Как отразиться на навыках именования переменных?

1. Людям нравится фокус, и это ключевой момент ключа

Одинокие паруса плывут далеко в голубое небо, виднеется только река Янцзы, текущая в небе.

Лэй Цзюнь сказал, что написание кода похоже на написание стихов, которые не являются пустым выражением. Имена переменных в коде, как и поэзия, опускают лишние детали, сохраняют самые критические слова, и чем конкретнее слова, тем лучше расплывчатые и неточные.

Напишите больше стихов или потренируйтесь в классическом китайском языке, чтобы улучшить свои языковые навыки и помочь улучшить свои навыки именования переменных.

2. Люди любят классифицировать, особенно визуально

Расположение кода также имеет визуальные эффекты.Одна и та же обработка одного и того же ресурса может быть объединена, одна и та же обработка может быть объединена, и один и тот же тип обработки также может быть объединен.

Иногда между разными категориями возникают конфликты, которые не могут быть удовлетворены одновременно. В это время вам нужно найти ключевую категорию и сосредоточиться на ней, если вы не можете ее найти, попробуйте еще, подкорректируйте и почувствуйте изменения.

С точки зрения именования переменных, попробуйте объединить одну и ту же категорию вместе, визуально и концептуально их можно обрабатывать как визуальный блок, чтобы уменьшить место, занимаемое в рабочей памяти.

В настоящее время хорошо классифицированные чистые функции имеют большие преимущества.Шаблоны кода чистых функций очень похожи.Тело функции сначала содержит пару операторов присваивания с характером get, а затем возвращает выражение.

Режим get -> return позволяет разработчикам иметь ожидания при переходе к определению функции (предварительно загружать психологическую основу для соответствующей идентификации кода, повышать эффективность чтения кода и поддерживать поток).

3. Люди любят многослойность, особенно слой за слоем

Когда все очень сложно, нам нравится видеть слои вещей, каждый слой прост, и он становится сложным, когда организован, но в это время за сложностью скрывается простота, и она не кажется такой сложной.

• Наслоение пространственных измерений в основном разбивается на блоки.Большая задача разбивается на несколько составляющих, и каждая составляющая обрабатывается детально.

• Наслоение временного измерения в основном происходит поэтапно, когда большая задача делится на несколько этапов, и каждый этап обрабатывается подробно.

• Наслоение концептуальных измерений в основном происходит от специального к общему, обобщая набор конкретных задач до более общих сценариев, а затем уточняя их обратно посредством параметризации.

Три метода наложения обеспечивают основу для именования переменных.

• xPartOfThing представляет часть x после пространственного измерения, также может быть yPartOfThing и т. д., то есть мы можем сначала указать заполнитель, не называя его конкретно. Мы знаем только уровень Thing, и мы недостаточно знаем о его детальных компонентах.Если мы не знаем, как его назвать, мы можем временно назвать его xPartOfThing, а затем, когда код будет реализован, мы узнаем больше о его компонентах. компонентов и может назначать более конкретные имена переменных.

• xPhaseOfThing представляет фазу x после наслоения временного измерения, которое совпадает с наслоением пространственного измерения, а имя конкретной фазы будет уточнено позже.

• xLayerOfThing представляет уровень x после стратификации измерения концепции, а затем присваивает новое имя после того, как проблема будет более четко понята.

Увидев это, некоторые читатели могут задаться вопросом, получается, это не одноразовая штука с именованием, а необходимо постоянно рефакторить код и корректировать имена переменных?

Правильно, элегантный код не делается за один раз и не стремится быть сделанным за один раз. Причина, по которой программное обеспечение является программным, а не аппаратным, заключается в том, что его легче редактировать и многократно настраивать, обновлять и повторять.

К изменению кода нас подталкивают не только новые требования, но и новое понимание проблемы.

Не скупитесь на изменение имен переменных.

4. Люди любят оправдываться

Когда мы оправдываем это, кажется, что ум активизирован, креативен, пытается построить более полную структуру и счастлив.

Как это обосновать в коде? Организуем наш код по домену (domain), выходному интерфейсу (interface).

Эта организация кода может помочь разработчикам выполнять описанную выше (пространство, время и концепцию) иерархическую обработку в определенной области.

В настоящее время идея именования переменных подобна пружине, и она бесплатна.

Например, при написании веб-фреймворка, работающего с доменом, связанным с сервером, HttpRequest, HttpResponse, HttpHeaders, HttpMethod, Url, JsonResponse, HtmlResponse, FileResponse...

Многие элементы, связанные с предметной областью, вдохновят разработчиков на присвоение имен переменным. Однако это работает только в том случае, если мы организуем код по доменам. Просто следуя линейному процессу выполнения задач программирования, реализуя и решая их одну за другой, вы сталкиваетесь с переплетением блоков, фаз и концепций из нескольких областей.

Такое переплетение не способствует сосредоточению внимания на какой-либо одной области для более всестороннего понимания и общего планирования, а также значительно увеличивает когнитивную нагрузку. Блок памяти легко занять.Больше оперативной памяти.

Каждый раз, когда фокусируется одна область, слои и блоки, а также их отношения внутри этой области будут более естественно сочетаться друг с другом в познании и рассматриваться как единое целое. Наша тенденция оправдывать себя будет сосредоточена на структурной или иерархической целостности симметрии, двойственности и замкнутых контуров поля.

Например, если у вас есть open, вы думаете о закрытии, если у вас есть get, вы думаете о наборе, если у вас есть add, вы думаете об удалении и так далее. Эти различные операции, которые часто появляются вместе, имеют имена переменных.

Что еще более важно, самообоснование нескольких отдельных полей позволяет добавить высококачественные активы кода в нашу кодовую базу.Многие основные проблемы полей были решены, и мы можем сосредоточиться на бизнес-логике высокого уровня при написании кода.

5. Люди тоже любят абстракцию

Раньше я говорил, что людям нравится конкретное, а здесь я говорю, что людям нравится абстрактное, разве это противоречиво?

Не противоречиво.

Много раз люди неправильно используют слово «абстрактный» и называют расплывчатые и неточные вещи «слишком абстрактными».

Много раз люди неправильно понимали слово «абстракция» и не учились, а называли «слишком абстрактными».

Людям нравятся конкретные вещи, но это не значит, что они не любят абстрактные вещи. Люди лучше обрабатывают конкретные вещи, потому что стимуляция конкретных вещей более распространена в повседневной жизни, а стимуляция абстрактных вещей требует дополнительного творчества.

Другими словами, источник стимула абстрактных вещей относительно скуден.

Здесь нам нужно ввести понятие «профессиональное обучение».Так называемое профессиональное обучение заключается в повышении уровня стимуляции абстрактных вещей в конкретной области, чтобы мы также могли установить лучший уровень обработки терминологии в конкретной области. .

Большинство программистов прошли профессиональную подготовку с базовыми знаниями в области программирования. Для таких терминов, как переменные, функции, циклы, классы, наследование и т. д., он имеет лучшую эффективность обработки (чувствовать себя интуитивно), чем обычные люди.

Но недостаточно написать элегантные имена переменных и написать элегантный код.

Элегантный код часто содержит абстрактные знания в двух основных областях:

• поле кода
• проблемная зона

Разработчикам необходимо не только овладеть знаниями в области программирования, но также необходимо овладеть знаниями о проблемах в предметной области, с которыми они сталкиваются, и органично интегрировать их. Это тактическая часть предметно-ориентированного проектирования (DDD), как программно воспроизвести концепции и организационные отношения в бизнес-модели предметной области.

Фреймворки есть не только в области кода, но и в области, не связанной с кодом, тоже есть фреймворки. Например, математика является основой знаний во всех областях.

Даже в математике есть свои подразделения, в которых даже есть подразделения математической природы математики, которые можно назвать рамками математической теории, например Теория категорий.

Обучение использованию фреймворков может помочь нам быстрее понять и решить проблемы, связанные с предметной областью.

Изучение фреймворка может помочь нам быстрее построить фреймворк для предметной области.

Есть также сходство между фреймами и фреймами, которые также могут быть интегрированы и органично организованы.

Например, модель CRUD для ресурсов является основой для многих конкретных моделей бизнес-доменов. Многие проблемы можно смоделировать как процессы управления конкретными ресурсами.

Обработка ресурсов CQRS — это дальнейшее усовершенствование модели CRUD. Его вклад в основном состоит в том, чтобы разделить модель чтения/записи, подчеркнув наслоение технических областей и областей бизнеса. CRUD — это концепция в технической области с небольшим количеством ограничений, в то время как модели в бизнес-сфере часто требуют больше ограничений, чем добавление, удаление, изменение и проверка по желанию. CQRS делает упор на построение модели запросов таким образом, чтобы она соответствовала бизнес-модели.Чтобы запрашивать ресурсы, создайте командную модель для обновления ресурсов.

Эти вещи считаются - архитектурой.

• Фреймворк — это абстракция конкретной предметной проблемы.
• Фреймворк (архитектура) фреймворка — это абстракция организационных отношений множества предметных проблем.
• Каркас каркаса Каркас (система) — это абстракция организационных отношений множества организационных отношений...
• Каркас каркаса Каркас каркаса (парадигма) — это абстракция организационных отношений организационных отношений множественных организационных отношений
• Структура четвертого порядка является абстракцией организационных отношений структуры третьего порядка.
• Фрейм порядка n является абстракцией организационных отношений фрейма порядка n-1.

Людям нравится абстракция, и им нравится видеть вышеизложенное разделенным на несколько параллельных сводок, каждый раздел представляет собой своего рода прогрессивную абстракцию предыдущего раздела, содержащую определенный образец вещей (по сути, индукция).

Людям нравится абстракция, но способность абстрагироваться требует профессиональной подготовки.Процесс профессиональной подготовки — это процесс обучения, а процесс обучения часто содержит множество препятствий, таких как замешательство и стресс. Мы часто неправильно понимаем себя, что нам не нравится абстракция.

Мы любим их, когда успешно осваиваем определенный уровень абстракции.

Чем больше абстракций вы освоите, тем организованнее и проще будет писать кодовые имена.

Мы можем сначала написать код с более широким абстрактным словарем, таким как getResource, setResource, queryRespurce, sendCommand и т. д., а затем заменить код более конкретным именем операции и именем ресурса после написания кода.

Другими словами, абстрактная структура ускоряет сходимость нашего кодового именования, и нам не нужно блокировать, потому что мы не знаем конкретного имени.Хотя мы не знаем конкретного имени, мы знаем, что оно должно принадлежать какому-то своего рода более широкое понятие/ресурс/ Один из шаблонов, мы сначала используем аннотацию в качестве заполнителей и продолжаем расширять код. Когда все будет готово, мы вернемся и назначим новые имена переменных одно за другим.В это время у нас будет более полное и всестороннее понимание проблемы, и мы будем знать положение каждого имени переменной во всей картинке кода. .

В общем, людям нравится абстракция и не нравится абстракция, которой они не овладели.

6. Люди чувствительны к тенденциям и целям

Люди — предсказуемые животные, мы всегда пытаемся предсказать, как что-то изменится, используя ограниченные подсказки, и чувствуем себя счастливыми, потому что вещи совпадают с нашими прогнозами.

Как эту функцию можно использовать для оптимизации именования переменных?

Включайте тенденции, цели и задачи в имена переменных (особенно в имена функций), чтобы выразить намерение изменений ресурсов.

Например, общая обработка обновления данных setCount(count + step) инкапсулирована в увеличениеBy(step), чтобы выразить намерение и тенденцию изменений данных, и появятся его операции, связанные с предметной областью, такие как уменьшениеBy(шаг), setMax( maxValue ), setMin(minValue), animateTo(targetCount).

Только когда Count Domain отделен от простой общей технической семантики, могут быть достигнуты минимальные и максимальные ограничения.CountDomain#increaseBy(step) — это увеличение в контексте конкретного домена, которое может отбросить значение переполнения.

С чисто технической семантикой setCount(newCount) трудно допустить, что count не равен newCount, если только функция не возвращает логическое значение и другую информацию, чтобы сообщить внешнему, был ли результат обновления успешным и почему обновление не удалось.

Добавление намерений к именам переменных часто делает имя переменной слишком многословным. Это неизбежно и требует много тренировок, чтобы улучшить способность представлять «ключевые конкретные» элементы, упомянутые в первой статье, то есть способность писать стихи.

7. Люди любят честные вещи

Что такое искренний кодекс, что он говорит, то он говорит, что он говорит, то и делает, он предназначен для искренности.

Имена переменных многих кодов изменились в семантической логике, и если они не изменились, значения выполнения программы и имен переменных могут быть даже изменены на противоположные.

Многие разработчики, чтобы упростить длину кода, чрезмерно сжимают и устраняют множество модификаций префиксов, чтобы в конкретном коде были более широкие существительные, а степень абстракции не соответствовала, что преувеличено.

Каждый раз, когда вы разрабатываете небольшой модуль, вам необходимо провести общую «честную проверку», чтобы убедиться, что код делает то, что он говорит.

Эта проверка может показаться хлопотной, и поначалу это действительно обременительно, но это того стоит. Эта проблема не постоянна, и по мере того, как мы знакомимся и совершенствуем свои навыки именования, требуемое время проверки будет уменьшаться. Кроме того, на этапе обзора часто можно создать новые возможности для модификации.

Суммировать

Мы можем перечислить еще элементы и приемы, но это не обязательно, потому что вышеперечисленное на самом деле является некоторым тактическим содержанием.

Если вы сможете внести коррективы в стратегическое мышление, сами разработчики смогут обобщить вышеизложенное на практике. И если стратегический менталитет не изменится, вышеперечисленные тактические элементы будут нам только мешать и станут очередной "слишком абстрактной", "слишком реалистичной", "слишком идеализированной" вещью.

Истинная ценность и смысл этих тактик не чувствуется.

Так что же это за стратегическое мышление?

Является ли это нашим фундаментальным отношением к коду, рассматриваем ли мы написание кода как инструмент для достижения цели, или это деятельность с самоцелью, такая как написание статьи или даже стихотворения?

Чтобы писать хорошие статьи и стихи, мы будем рассматривать слова и неоднократно их пересматривать.Прилагаем ли мы такие же усилия для кода?

Мы рассматриваем наши статьи и книги как ценные личные творения и активы. Мы смотрим на наш код с одной и той же точки зрения?

Чувствуем ли мы себя раздражительными или счастливыми в процессе постоянного извлечения подфункций? Чувствуете хлопоты или считаете, что добавили качественные активы кода и добавили понимание проблемы?

Многие разработчики часто говорят, что код — это инструмент для решения проблем, не думайте о проблемах с узкой технической точки зрения. Я подчеркиваю здесь, что целью является сам код, не слишком ли он технологичен и не достоин подражания?

Нет, конфликта нет.

У людей не только одна цель, но во многих разных ситуациях есть разные цели и средства.

Код по-прежнему является инструментом для решения бизнес-задач, но если вы хотите писать хороший код, вы должны ставить хороший код в качестве цели при написании кода.Этот менталитет никак не влияет на инструментальный атрибут кода на уровне решения проблем.

Целью этого уровня может быть инструмент другого уровня, совместимый друг с другом.

Разработчики, которые всегда рассматривают технологии и код как инструменты, могут в конечном итоге заблокировать свои технические достижения.Они не воспринимают код и технологии всерьез, вкладывают недостаточно средств и склонны сталкиваться с техническими ограничениями.

И разработчики, которые всегда рассматривают технологии и код как свою цель, в конечном итоге будут страдать от нетехнических возможностей.

С точки зрения отношения к коду нам также нужна многоуровневая обработка, упомянутая выше многоуровневая обработка находится на уровне когнитивной психологии человека, а не только для написания кода.

Ключ в том, чтобы улучшить наш когнитивный уровень, а способность писать код — это применение когнитивного уровня. Во многих случаях не отсутствие навыков программирования мешает нам писать элегантный код, а отсутствие понимания проблемы.

Техника назначения абстрактных переменных-заполнителей описана выше и предназначена для разблокировки программирования, содействия обработке проблем, накопления понимания проблем, улучшения познания, а затем возврата имен переменных.

Элегантные имена переменных возникают не только благодаря навыкам программирования, но и благодаря знанию предметной области.

Когнитивные установки и уровни являются стратегическими, навыки и опыт программирования — тактическими.

По мере повышения уровня стратегии время, которое мы тратим на чтение, общение и размышления, увеличивается, а доля времени, затрачиваемого на кодирование, уменьшается, но качество и эффективность повышаются.

Повышение эффективности кода, с одной стороны, происходит от понимания проблем предметной области, а с другой стороны, после освоения упомянутой выше высокоуровневой абстракции (каркас каркаса каркаса...), мы можем построить без фактического написания кода модель программирования.

Поскольку мы освоили взаимосвязь между техническими понятиями в программировании, мы знаем, что с помощью x мы можем решить X, с помощью y мы должны иметь z, а с помощью операции и b элементов мы можем сформировать c-структуру, выразить d-намерение, положить Достигнув модуля e, его можно использовать как функцию g слоя f...

Большая профессиональная подготовка позволяет нам понять взаимосвязь между абстрактными вещами в технической области так же легко, как любители развлечений знакомы со сплетнями об отношениях между айдолами.

Проблема именования переменных — это не проблема именования переменных, а проблема когнитивного уровня и профессиональной подготовки.

Каждый раз, когда мы серьезно полируем код и изучаем больше абстрактного программирования и математических знаний, мы проводим профессиональное обучение, чтобы подготовиться к более качественной обработке абстрактных концепций в следующий раз. Элегантные имена переменных, побочный продукт этого.

Начните с изменения своего отношения к коду и попробуйте писать код как стихи.

Если хочешь быть бедным, переходи на следующий уровень