аминь :)

{#"(['re]{3})" " are"
 #"(['m]{2}$)"  " am"}

you've been much happier to have your data be smart and your program be dumb
(c) Stu

всё правильно сказал

Прочел две части с удовольствием. По поводу второй высказываются двояко. В комментариях. Кода больше раза в три. Совершить ошибку в найминге при обращении к функции легче. Тестить надо 8 функций а не одну. Что ты об этом думаешь? Код, по сравнению с начальным вариантом, конечно же приятнее смотрится, как по мне. И последнее: почему автор вынес расчет возведения в квадрат в отдельную функцию? Это обусловлено тем, что "функция должна делать одну вещь"?

про какую вторую часть речь?

Деление на небольшие функции. Там ведь о нейминге сразу писал

а первая часть тогда что?

а, понял

я сам не вчитывался, это для иллюстрации принципа было

у кода главная задача (помимо работоспособности) - поддерживаемость, т.е. читабельность, так что "приятно смотрится" - это многое

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

ну реально, код читается гораздо больше, чем пишется

Да. Я понял что для иллюстрации. Мне просто была не до конца понятна позиция недовольного комментатора

любой

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

Тоже согласен. Даже не три в одном а 33 в одном. Сам таким страдаю

поддерживаемость — это в частности, тестируемость, удобность при рефакторинге, понятность, почему код написан именно так

Сейчас в поезде. Чтобы ещё полезного почитать?

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