Просто хотелось высказаться о наболевшем. Большая часть кода, которую мне приходится просматривать, делится на две категории - код, который совсем не разбит на функции и идёт сплошным потоком, и код, который чрезмерно разбит. И вот первый код проще читать оказывается. Почему-то большинство программистов, которые открыли для себя паттерны проектирования, не могут остановиться на золотой середине, и безмерно лепят абстракции, что потом даже сами разобраться не могут в своём коде..
Я обычно когда пишу код под свои задачи, я пишу его одним потоком. Потом выношу те куски, которые мешают читабельности (или могут быть переиспользованы) в отдельные функции. Иногда и из функций выношу куски кода в другие функции, в основном, только в соображениях переиспользования. Уровень вложенности функций больше двух - редкость. Только после этого я могу комфортно вернуться к этому коду даже через год.
Это такая старая добрая традиция борцунов - трясись от каждого шороха? И у меня нет никаких дружков в "госдуре", с чего вы решили? Просто если начинаешь смотреть на мир реалистично, а не через призму глупых надуманных категорий, то нервная система здоровее оказывается.
А какую практическую пользу вам даст ответ на ваш вопрос? Если вы к своим годам (а вам врядли 8 лет) не знаете даже самые известные художественные произведения? Нет, это не Волан де Морт (прочитайте другую книгу), это автопортрет Ван Гога. Надеюсь, вам это поможет в вашей практике.
Даже если забить, что автор чётко прописал условие, и никаких трудных времён там нет... Пересчитайте, даже если семья перестаёт заводить детей после рождения мальчиков, разнополых детей в итоге оказывается поровну.
(Подсказка: если 50% семей родили мальчиков, а 50% девочек, то на данном этапе детей поровну, и задача решается снова для той половины, которая родила девочек)
На моём опыте, код, в котором каждые несколько строчек вынесены в методы с "самодокументируемыми" названиями, читать гораздо сложнее, чем код, где блоки кода обернуты в понятные комментарии. В первом случае, в таком спагетти-коде приходится рыться, пробираясь через кучу функций, которые вызывают другие функции, а те в свою очередь третьи. Если для автора кода очевидно, что делает функция enableGradientClipping(model), то для меня не очевидно ни что она делает, ни как она реализована, что часто тоже важно. Открываешь функцию, она оборачивает другую функцию setClipNorm, но с проверками на дурака и ассертами. Открываешь и её, а внутри просто вызов библиотечной функции из torch. Часто натыкаюсь на репозитории, которые на 90% состоят из "самодокументируемых" функций, из-за которых код приходится читать в 3 раза дольше.
Согласен с вами, если статья именно об этом.
Просто хотелось высказаться о наболевшем. Большая часть кода, которую мне приходится просматривать, делится на две категории - код, который совсем не разбит на функции и идёт сплошным потоком, и код, который чрезмерно разбит. И вот первый код проще читать оказывается. Почему-то большинство программистов, которые открыли для себя паттерны проектирования, не могут остановиться на золотой середине, и безмерно лепят абстракции, что потом даже сами разобраться не могут в своём коде..
Я обычно когда пишу код под свои задачи, я пишу его одним потоком. Потом выношу те куски, которые мешают читабельности (или могут быть переиспользованы) в отдельные функции. Иногда и из функций выношу куски кода в другие функции, в основном, только в соображениях переиспользования. Уровень вложенности функций больше двух - редкость. Только после этого я могу комфортно вернуться к этому коду даже через год.
Это такая старая добрая традиция борцунов - трясись от каждого шороха? И у меня нет никаких дружков в "госдуре", с чего вы решили? Просто если начинаешь смотреть на мир реалистично, а не через призму глупых надуманных категорий, то нервная система здоровее оказывается.
А какую практическую пользу вам даст ответ на ваш вопрос? Если вы к своим годам (а вам врядли 8 лет) не знаете даже самые известные художественные произведения? Нет, это не Волан де Морт (прочитайте другую книгу), это автопортрет Ван Гога. Надеюсь, вам это поможет в вашей практике.
Даже если забить, что автор чётко прописал условие, и никаких трудных времён там нет... Пересчитайте, даже если семья перестаёт заводить детей после рождения мальчиков, разнополых детей в итоге оказывается поровну.
(Подсказка: если 50% семей родили мальчиков, а 50% девочек, то на данном этапе детей поровну, и задача решается снова для той половины, которая родила девочек)
На моём опыте, код, в котором каждые несколько строчек вынесены в методы с "самодокументируемыми" названиями, читать гораздо сложнее, чем код, где блоки кода обернуты в понятные комментарии. В первом случае, в таком спагетти-коде приходится рыться, пробираясь через кучу функций, которые вызывают другие функции, а те в свою очередь третьи. Если для автора кода очевидно, что делает функция enableGradientClipping(model), то для меня не очевидно ни что она делает, ни как она реализована, что часто тоже важно. Открываешь функцию, она оборачивает другую функцию setClipNorm, но с проверками на дурака и ассертами. Открываешь и её, а внутри просто вызов библиотечной функции из torch. Часто натыкаюсь на репозитории, которые на 90% состоят из "самодокументируемых" функций, из-за которых код приходится читать в 3 раза дольше.
Вы, кроме Навального, ещё что-то посмотрите, в музеи сходите, в галереи, и такие вопросы даже в голову не прийдут