Лучше добавить условие внутри или снаружи для l oop для более чистого кода? - PullRequest
0 голосов
/ 26 января 2020

Так что это может показаться простым, но у меня есть метод, который имеет для l oop внутри, внутри forl oop, метод createprints нуждается в карте «параметров», которую он получает из getParameters, теперь есть 2 типы отчетов, один имеет общий набор параметров, а другой имеет этот общий набор и собственный набор.

У меня есть два варианта:

Либо есть метод 2 getparameters, один из которых является general и другой, который предназначен для rp2, но также вызывает метод общих параметров. Если я сделаю это, то имеет смысл добавить условное выражение перед для l oop следующим образом:

    theMethod(){

        if (rp1){
            for loop{
                createPrints(getgenParameters())
                do general forloop stuff 
           }
        }else{
              for loop{
                createPrints(getParameters())
                do general forloop stuff
                }
        }
    }

Таким образом, он только один раз проверяет, какой метод параметров вызывать, вместо того, чтобы иметь оператор if внутри l oop, так что он проверяет каждую итерацию (это плохо, потому что тип отчета никогда не изменится в течение l oop), но тогда повторение for l oop выглядит некрасиво и совсем не чисто Есть ли более чистый способ создания этого?

Другой вариант - передать логическое значение в метод get параметров, и в основном вы проверяете, в каком типе отчета это происходит, и на основании того, что вы создаете карту, однако это также добавляет условное выражение на каждой итерации.

С точки зрения производительности имеет смысл иметь условное выражение вне l oop, чтобы оно не проверялось избыточно на каждой итерации, но оно не выглядит чистым, и мой босс действительно заботится о том, как выглядит чистый код, ему не понравилось, что я использовал блок кода if else вместо того, чтобы делать это это троичные операторы, так как троичный использует только одну строку (я думаю, что производительность все та же нет?).

Забыл упомянуть, что я использую java, я не могу назначать функции переменным или использовать обратные вызовы Внутри метода был блок кода if else перед для l oop что-то вроде

String aVariable;

if(condition){
aVariable= value1;
}else{
aVariable =value2;
}

, поэтому я изначально хотел просто создать логическую переменную вроде isreport1 и внутри блока кода if / else также назначьте значение, потому что оно использовало то же условие. И затем, как упоминалось ранее, передайте параметр, но мой босс снова сказал, что не следует использовать логические значения в параметрах, так что, в таком случае, я не должен делать это здесь?

Ответы [ 3 ]

1 голос
/ 27 января 2020

Прогноз ветвления является свойством процессора, а не компилятора. Все современные процессоры имеют это, не волнуйтесь.

Большинство компиляторов могут вывести постоянное условие из l oop, так что не беспокойтесь снова. Java тоже так делает. Детали: javac компилятор этого не делает, его задача - преобразовать исходный код в байт-код и ничего больше. Но во время выполнения критичные по времени части байт-кода компилируются в машине, и там происходит много оптимизаций.

Забыл упомянуть, что я использую java, я не могу назначать функции переменным или используйте обратные вызовы.

Вы можете. Он реализован через анонимные классы и с Java 8 существуют лямбды. Конечно, стоит учиться, но не относится к вашему делу.

Я бы просто go за

       for loop{
            createPrints(rp1 ? getgenParameters() : getParameters())
            do general forloop stuff 
       }

, так как это самый короткий и чистый способ сделать это.

Существует множество альтернатив, таких как определение Parameters getSomeParameters(boolean rp1), которое вы можете легко создать, используя «метод извлечения» из вышеприведенной троицы.

С точки зрения производительности имеет смысл иметь условное выражение вне l oop, чтобы его не проверяли избыточно на каждой итерации, но он не выглядит чистым, и мой начальник действительно заботится о том, как выглядит чистый код

С точки зрения производительности все это не ' не имеет значения. Компилятор чертовски умен и знает массу оптимизаций. Просто напишите чистый код с помощью коротких методов, чтобы он мог правильно выполнять свою работу.

он мне не понравился, используя блок кода if else вместо того, чтобы делать это с троичными операторами, так как троичный использует только одну строку

Простой троичный однострочный код значительно облегчает понимание кода, поэтому вам нужно go для него (сложные троицы могут быть трудными для gr asp, но здесь это не так).

(мне кажется, производительность все та же, нет?).

Определенно. Обратите внимание, что

  • большинство частей программы не имеют значения для производительности (принцип Парето)
  • оптимизации низкого уровня редко имеют значение (компилятор знает их лучше)
  • чистый код с использованием правильные структуры данных имеют значение
0 голосов
/ 27 января 2020

В большинстве "споров" о том, является ли один способ написания некоторого фрагмента кода более эффективным, чем другой, не хватает смысла.

Компилятор JIT выполняет много оптимизаций для вашего кода за кулисами. Он (или, точнее, люди, которые его написали) знают о том, как оптимизировать, гораздо больше, чем вы. И у них будет преимущество в том, что они провели обширные сравнительные тесты и обходы кода (машинного уровня) и тому подобное, чтобы выяснить лучший способ оптимизации.

Компилятор также может оптимизировать более надежно, чем человек. И его разработчики постоянно улучшают его.

И компилятору не нужно платить зарплату за оптимизацию кода. Да. Каждый час, который вы тратите на оптимизацию, - это время, которое вы могли бы потратить на что-то другое.

Итак, лучшая стратегия для вас заключается в следующем:

  1. Сначала реализуйте код. Время, потраченное на оптимизацию при кодировании, вероятно, потрачено впустую. Это классическое c поведение «преждевременной оптимизации». Ваша интуиция, вероятно, недостаточно хороша, чтобы сделать правильный вызов на этом этапе. (Немногие люди достаточно умны ...)
  2. Далее приведите код в действие и прохождение его тестов. Оптимизация глючного кода не имеет смысла.
  3. Установите некоторые реалистичные c количественные цели для производительности. («Как можно быстрее» не является ни реалистичным c, ни количественным). Ваш код должен быть достаточно быстрым, чтобы соответствовать бизнес-требованиям. Если это уже достаточно быстро, то вы тратите время разработчика, оптимизируя его дальше.
  4. Создайте реалистичный c тест, чтобы вы могли измерить производительность вашего приложения. Если вы не можете (или не можете) измерить, вы не будете знать, достигли ли вы своих целей, или если конкретная попытка оптимизации улучшила ситуацию.
  5. Используйте профилирование, чтобы определить, какие части вашего кода Стоит усилий по оптимизации. Профилирование говорит вам горячие точки, где большую часть времени проводят. Сфокусируйся там ... не на вещах, которые исполняются только изредка. Вот тут-то и возникает правило 80-20.

Я бы поговорил об этом с моим боссом. Если у босса нет идеи о том, чтобы быть методичным и научным c относительно производительности / оптимизации, тогда не боритесь с этим. Просто делай то, что говорит босс. (Но если вы готовы вернуться назад sh, если вас обвиняют в пропущенных сроках, связанных с потерей времени на ненужную оптимизацию.)

Существует два вида эффективности в программной инженерии:

  • Эффективность программы
  • Эффективность программиста

Эти две эффективности конфликтуют.

0 голосов
/ 27 января 2020

Как насчет этого?

theMethod(getParametersCallback){

        for loop {
            createPrints(getgenParametersCallback)
            do general forloop stuff 
       }
}

. . .  . .

if (rp1){
    theMethod(getgenParameters)
}
else {
    theMethod(getParameters)
}
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...