Несмотря на то, что Python изначально заточен быть красивым и читаемым, превратить его в мешанину непонятных переменных оказалось достаточно легко. Для исправления этой ситуации мне посоветовали изучить книгу Роберта Мартина "Чистый код". Прочитал первые пару глав и уже понял, что нужно избавляться от части весьма вредных привычек. Оказалось, что сокращения не делают тебя крутым программистом, а скорее наоборот. Если коротко собрать основные тезисы: В качестве небольшого примера и для закрепления переписал одну из небольших функций для проверки правильности расстановки скобок. Хотя казалось бы, что можно запутать в 3 переменных. Но после корректировки даже этот небольшой участок стал выглядеть гораздо более осознанным.
Несмотря на то, что Python изначально заточен быть красивым и читаемым, превратить его в мешанину непонятных переменных оказалось достаточно легко. Для исправления этой ситуации мне посоветовали изучить книгу Роберта Мартина "Чистый код". Прочитал первые пару глав и уже понял, что нужно избавляться от части весьма вредных привычек. Оказалось, что сокращения не делают тебя крутым программистом, а скорее наоборот.
Если коротко собрать основные тезисы:
- Одно слово следует использовать для одной концепции и под одним словом всегда подразумевать один процесс. (если вдруг add мы используем для конкатенации строк, то не следует использовать его в методе, суммирующем значения)
- Стоит избегать лишних сокращений. Сейчас нет ограничения на длину имени и в большинстве современных инструментов есть автозаполнение, так что имя придется написать лишь 1 раз
- Избегать использовать имена имеющие конкретные значения в контексте языка программирования или системы (например List в Python, если данные хранятся не в списке)
- Имена должны удобно произноситься и читаться. В первую очередь с ними работают люди. (По этой же причине не стоит кодировать в именах дополнительную информацию. Новичкам придется изучать принятые коды, это дополнительное время и дополнительные риски ошибок)
- Чем выше вероятность поиска определенного имени, тем длиннее может быть его имя, чтобы не порождать списков одинаковых имен
- Код пишется для программистов, поэтому сначала желательно использовать имена из пространства решения (термины вне задачи stack, queue и т.д.), затем имена из пространства задачи (информацию по этим терминам программист может получить при постановке задачи)
- Безусловно круто и так же ужасно для читаемости, если программист может держать в уме множество однобуквенных переменных.
В качестве небольшого примера и для закрепления переписал одну из небольших функций для проверки правильности расстановки скобок. Хотя казалось бы, что можно запутать в 3 переменных. Но после корректировки даже этот небольшой участок стал выглядеть гораздо более осознанным.