Ответ на сообщение Re: Программист. пользователя andrew13
Я поэтому и оттенил - " в современном...". Развитие - оно и есть развитие... это НЕ сопровождение. Это ДОБАВЛЕНИЕ нового - т.е. того, чего раньше не было. Совсем не было.
Да ЕСТЬ ТАМ ПРОВЕРКА!!! Ровно та, которая нужна!
Итого:
1. Метод получает 4 параметра: размеры исходной картинки и размер прямоугольника, куды её вписать надобно...
Самое первое - ПРОВЕРЯЕМ исходную ширину на еённое наличие (не нуль, не фальш и т.д.), потому как для получения коэффициента на неё банально делить надобно. Затем считаем этот самый аспект по стороне и ПРОВЕРЯЕМ его на близость к нулю. Когда одно число делится на другое в результате получается ВЕЩЕСТВЕННОЕ число, которое НЕЛЬЗЯ сравнивать с нулем... а можно только отследить его близость к последнему... чего и делается. Здесь же, далее АНАЛОГИЧНО проверяем второй исходный размер и ТОЧНО ТАКЖЕ считаем и ПРОВЕРЯЕМ второй коэффициент на близость к нулю.
Всё это делается в ОДНОМ предложении if(), точнее в его условной части... И если только ВСЕ ПРОВЕРКИ пройдены успешно ( и только в этом случае!) попадаем на единственный оператор (правда тернарный), который возвращает результат МЕНЬШЕГО коэффициента. ВСЁ.
Любая НЕВЫПОЛНЕННАЯ проверка - приведет к генерации исключения.
Это так стало. Итого имеем общее количество операций (причем как для разбора интерпретатору, так и при выполнении) - СТРОГО НЕОБХОДИМОЕ для решения задачи. Можете упростить?
А теперь "как было":
1. Получаем избыточный параметр, который выделяет первое действие... вот никто даже не заинтересовался - куды же оно делось? А как показал греп по вызовам - ОНО НЕ ИСПОЛЬЗУЕТСЯ НИГДЕ. Удалено как бесполезно выполняемый код.
2. Условия в части if и elseif взаимно дополняют друг друга, а стало быть исполняется либо одно либо другое - одна из проверок ГАРАНТИРОВАННО излишня - т.е. "копрокод" по определению...
3. результат функции округления "давится" на вывод ошибок... ну да, как же без этого, если на ноль делить это "наше всё"! Только при этом, чего-чего присваивается, ась?
4. При внимательном рассмотрении, находим, что результат выполнения блоков от первого условия практически НЕ ЗАВИСИТ... потому как , что "горизонтальная" картинка (высота больше ширины), что наиборот, НО делается внутренняя проверка, что ЕСЛИ НЕ ПОЛУЧИЛОСЬ, ТО ДЕЛАЕМ НАОБОРОТ. То есть, в худшем случае, СЧИТАЕМ ДВАЖДЫ КАЖДУЮ ВЕЛИЧИНУ... Ну просто песня а не код!!! Интересно, раз ни у кого вопросов НЕ ВОЗНИКЛО - Вы все так пишете???
5. Ну и как тут совершенно никто НЕ ЗАМЕТИЛ - нет ни одной проверки параметров... только вот ошибки давим, потому как явно в отладке они лезли...
Да ЕСТЬ ТАМ ПРОВЕРКА!!! Ровно та, которая нужна!
Итого:
1. Метод получает 4 параметра: размеры исходной картинки и размер прямоугольника, куды её вписать надобно...
Самое первое - ПРОВЕРЯЕМ исходную ширину на еённое наличие (не нуль, не фальш и т.д.), потому как для получения коэффициента на неё банально делить надобно. Затем считаем этот самый аспект по стороне и ПРОВЕРЯЕМ его на близость к нулю. Когда одно число делится на другое в результате получается ВЕЩЕСТВЕННОЕ число, которое НЕЛЬЗЯ сравнивать с нулем... а можно только отследить его близость к последнему... чего и делается. Здесь же, далее АНАЛОГИЧНО проверяем второй исходный размер и ТОЧНО ТАКЖЕ считаем и ПРОВЕРЯЕМ второй коэффициент на близость к нулю.
Всё это делается в ОДНОМ предложении if(), точнее в его условной части... И если только ВСЕ ПРОВЕРКИ пройдены успешно ( и только в этом случае!) попадаем на единственный оператор (правда тернарный), который возвращает результат МЕНЬШЕГО коэффициента. ВСЁ.
Любая НЕВЫПОЛНЕННАЯ проверка - приведет к генерации исключения.
Это так стало. Итого имеем общее количество операций (причем как для разбора интерпретатору, так и при выполнении) - СТРОГО НЕОБХОДИМОЕ для решения задачи. Можете упростить?
А теперь "как было":
1. Получаем избыточный параметр, который выделяет первое действие... вот никто даже не заинтересовался - куды же оно делось? А как показал греп по вызовам - ОНО НЕ ИСПОЛЬЗУЕТСЯ НИГДЕ. Удалено как бесполезно выполняемый код.
2. Условия в части if и elseif взаимно дополняют друг друга, а стало быть исполняется либо одно либо другое - одна из проверок ГАРАНТИРОВАННО излишня - т.е. "копрокод" по определению...
3. результат функции округления "давится" на вывод ошибок... ну да, как же без этого, если на ноль делить это "наше всё"! Только при этом, чего-чего присваивается, ась?
4. При внимательном рассмотрении, находим, что результат выполнения блоков от первого условия практически НЕ ЗАВИСИТ... потому как , что "горизонтальная" картинка (высота больше ширины), что наиборот, НО делается внутренняя проверка, что ЕСЛИ НЕ ПОЛУЧИЛОСЬ, ТО ДЕЛАЕМ НАОБОРОТ. То есть, в худшем случае, СЧИТАЕМ ДВАЖДЫ КАЖДУЮ ВЕЛИЧИНУ... Ну просто песня а не код!!! Интересно, раз ни у кого вопросов НЕ ВОЗНИКЛО - Вы все так пишете???
5. Ну и как тут совершенно никто НЕ ЗАМЕТИЛ - нет ни одной проверки параметров... только вот ошибки давим, потому как явно в отладке они лезли...
"Только так, только личная инициатива и напряженная работа над собой. .. Нужно своей собственной рукой все делать" (с) В.В. Путин(а не на "вертикаль власти" надеяться)
