Здравствуйте, alzt, Вы писали:
A>Зависит от ситуации. В большинстве случаев — да. Это реально ни на что не влияет. Если это проект, где нужна скорость и есть бенчмарки, которые показывают, что 2 раза вычислить квадратный корень нельзя, тогда это не подходит. Но в большинстве случаев это будет преждевременной оптимизацией.
Не могу согласиться. Не делать лишние вызовы функции там, где это совсем не нужно? , более того, очевидно не нужно — это не преждевременная оптимизация, а просто правила написания хорошего кода.
A>Это означает, что пора создавать класс, который будет иметь функции someFuncWithClearName, someOtherFuncWithClearName и т.д. и кешировать свои данные, чтобы этот корень дважды не вызывался.
Тоже не могу согласиться. Заводить новый класс ради таких пустяков, тратить бог знает сколько памяти на это кеширование — с хорошей точностью хранить таблицу квадратных корней без серьезного расхода памяти невозможно, а обычное хеширование приведет к существенной просадке скорости, так как на одну машинную команду FSQRT будет приходиться десяток-два команд для поиска в хеш-таблице Да и смысла в этом нет, так как основная идея кеширования — повторяемость запросов, а тут этого ждать не приходится.
>Тормозить по факту будет что-то другое.
Ну а у меня тормозил именно sqrt, и настолько, что я вынужден был произвести аналитические преобразования в условии и избавиться от квадратного корня вообще.
>А может вообще пора наплодить интерфейсов, написать фабрик и декораторов.
М-да...
>И я не утрирую и не иронизирую. Зависит от ситуации, но почти всегда это будет лучше, чем то, что было описано выше. Потом менять что-то будет сильно проще. И не обязательно брать какого-то волшебного человека, который в этом разбирается, досаточно просто обычного программиста.
Только с этим согласиться могу. Найти программиста, который ради четырех строчек вычисления корней квадратного уравнения наплодит новые классы, интерфейсы, декораторы и прочие паттерны, сделает код на сотню строк, потратив на это полдня — тут и впрямь проблемы нет.
В остальном же, видим, позиции у нас не только не совпадающие, а диаметрально противоположные, и едва ли удастся их сблизить.
Поэтому продолжать не буду. За тобой, конечно, право на ответ.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Не могу согласиться. Не делать лишние вызовы функции там, где это совсем не нужно? , более того, очевидно не нужно — это не преждевременная оптимизация, а просто правила написания хорошего кода.
Я не понял о чём это предложение. Вызов функции является способом оформить свои мысли, и это является правилом написания хорошего кода.
Если ты про тоже — то я согласен.
PD>Тоже не могу согласиться. Заводить новый класс ради таких пустяков, тратить бог знает сколько памяти на это кеширование — с хорошей точностью хранить таблицу квадратных корней без серьезного расхода памяти невозможно, а обычное хеширование приведет к существенной просадке скорости, так как на одну машинную команду FSQRT будет приходиться десяток-два команд для поиска в хеш-таблице Да и смысла в этом нет, так как основная идея кеширования — повторяемость запросов, а тут этого ждать не приходится.
А при чём здесь кеширование? В С++ никаких накладных расходов на класс не будет. Если это Java, то там вообще никого не волнует производительность. Основные проблемы с кодом случаются не из-за производительности, а из-за того, что другим программистам сложно читать код и они не понимают, что происходит. Класс упрощает эту задачу. Понятно, что будут задачи, где один толковый человек с опытом сможет разобраться за пару часов, и там важна скорость. Тогда да — к чёрту красивый код, пусть пишет так, чтобы работало быстро. Но обычно по другому.
PD>Только с этим согласиться могу. Найти программиста, который ради четырех строчек вычисления корней квадратного уравнения наплодит новые классы, интерфейсы, декораторы и прочие паттерны, сделает код на сотню строк, потратив на это полдня — тут и впрямь проблемы нет.
Все эти декораторы по факту упрощают дальнейшую работу с кодом. Если что-то надо добавить, то знаешь, что у тебя полно тестов и можно менять код. И достаточно найти место, где описывается некоторая логика, и всё. Не надо знать 10 тысяч правил как этот код работает и где будут сайд эффекты. И почти всегда на скорость это не влияет.
