Про читабельный код 2/2
Чтобы не тянуть кота за хвост, сразу же брошу пару-тройку рекомендций, пока они у Меня в голове. Особенно будут особенно полезны начинающим специалистам, но может и матёрым волкам что-то из этого пригодится.
1. Выступление автора библиотеки Keras, "The Secrets of Productive Developer Tools"
Идея: писать код, фокусируясь на том, кто его будет использовать и как; думать о UX, который ты задаёшь своим кодом (какой workflow?); параметры и наименования должны отражать что пользователь твоего кода получает, а не как этот код реализован (мысль тривиальная, но...)
2. Книга Егора Бугаенко, "Elegant Objects"
Идея: "уважать" объекты, воспринимать их как автономные сущности с которыми можно и нужно взаимодействовать, а не как набор переменных, сброшенных в одну кучу (откуда всегда можно что-то взять или положить через сеттеры и геттеры); когда мы что-то хотим получить от объекта, мы должны попросить (делегировать), а не микроменеджерить объекты, вмешиваясь в их логику работы и отдельно диктуя что с чем сделать.
В частности, автор пропагандирует, что все процедуры должны быть глаголами (действиями), а все функции (когда что-то возвращается) – существительным или существительным с прилагательным. Почему? Названием функции мы описываем что пользователь получит.
Аналогия: что когда мы приходим в ресторан, мы говорим, "Мне, пожалуйста, латте" (
Собственно, даже если вы пишите MVP на коленке, говнокодя как последний подонок, хотя бы заботьтесь о внятном именовании с понятной логикой. Нормальные именования – это уже залог 80% читабельности кода.
Чтобы не тянуть кота за хвост, сразу же брошу пару-тройку рекомендций, пока они у Меня в голове. Особенно будут особенно полезны начинающим специалистам, но может и матёрым волкам что-то из этого пригодится.
1. Выступление автора библиотеки Keras, "The Secrets of Productive Developer Tools"
Идея: писать код, фокусируясь на том, кто его будет использовать и как; думать о UX, который ты задаёшь своим кодом (какой workflow?); параметры и наименования должны отражать что пользователь твоего кода получает, а не как этот код реализован (мысль тривиальная, но...)
2. Книга Егора Бугаенко, "Elegant Objects"
Идея: "уважать" объекты, воспринимать их как автономные сущности с которыми можно и нужно взаимодействовать, а не как набор переменных, сброшенных в одну кучу (откуда всегда можно что-то взять или положить через сеттеры и геттеры); когда мы что-то хотим получить от объекта, мы должны попросить (делегировать), а не микроменеджерить объекты, вмешиваясь в их логику работы и отдельно диктуя что с чем сделать.
В частности, автор пропагандирует, что все процедуры должны быть глаголами (действиями), а все функции (когда что-то возвращается) – существительным или существительным с прилагательным. Почему? Названием функции мы описываем что пользователь получит.
Аналогия: что когда мы приходим в ресторан, мы говорим, "Мне, пожалуйста, латте" (
latte) – называешь, что хочешь получить. Мы не говорим "заварите Мне латте" (brew_latte) или "принисите Мне латте" (get_latte). N тем более мы не идём на кухню, диктовать баристе в какой питчер заливать молоко. Это было бы странно. Но в среднестатистическом коде подобное встречается тут и там.Собственно, даже если вы пишите MVP на коленке, говнокодя как последний подонок, хотя бы заботьтесь о внятном именовании с понятной логикой. Нормальные именования – это уже залог 80% читабельности кода.