Что именно проверять, если в этом цикле нет проверок?

Сплошное склеивание строк.

Вообще-то GenCloud не об этом писал, но этот вариант тоже неплох.

Рассматривает 1 строку

replyMSG.append("" + event.getName() + "" + "" + "" + "");

есть высокая вероятность что оптимизатор не будет делать пример, когда каждое объединение будет выполняться с созданием нового StringBulder, было бы глупо так делать, а разработчики java судя по всему не так глупы. Это все может быть как раз переведено в код с 1 классом StringBuilder и append.

Это рассуждения конечно, но и решать сразу что оптимизатор пойдет по медленному пути не правильно.

В случае с использованием "+" внутри .append() (как у Вас и сделано) код превратится вот в это :

Код:


Т.е. каждую итерацию цикла будет создаваться новый экземпляр StringBuilder.

Зачем это, если Вы уже используете TextBuilder, и можете использовать .append(), вместо использования "+" ?

Да, именно и нужно "склеивание 2 строк" в верхнем блоке с проверками, а в нижнем передано на решение оптимизитора java.

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

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

Ничего необычного в общем-то.

Вторая подсказка - методы данного класса используются только на момент настройки эвентов. Настройка эвентов происходит редко.

Вопрос - нужно ли оптимизацию скорости выполнения без конкатенций в проверках выносить ключевым?

Вопрос - нужно ли оптимизация строки генерирования странички html выносить ключевым?

Вопрос - нужно ли поставить ключевым вопрос ООП и экономии памяти из-за крайне редкого использования?

Можно было бы городить велосипед для 2-3 циклов с 1 экземпляром билдера, но для пары-тройки итераций код будет излишним, а вопрос скорости работы не решит. То есть создание 1 или 2 билдеров - это скажем так "оптимизация" весьма не очень полезная, выигрыш может и будет несколько наносекунд, но я считаю, что лаконичность кода в данном случае лучше.

А назвать этот конкретный цикл прямо говнокодом - это уже ни в какие ворота.

А если бы здесь было 9000 ивентов, то можно?

Суть в том, что условности рода "предполагается, количество ивентов не превысит 2-3" не дают права писать подобные конструкции.

Естественно, это Ваш проект, и Вам решать, как Вам удобнее работать и какие условности соблюдать.

Вот только этот код каким-то образом стал публичным, следовательно он подчиняется правилам общего использования.

Настоятельно прошу не пропускать мои сообщения через призму токсичного первого поста GenCloud.

Мало того, когда 1 итерация цикла, получается что явное объявления билдера перед циклом выглядит громоздко и может претендовать на звание "говнокод".

Или ты (имеется ввиду velafrys) прямо сразу исключаешь такое граничное условие?

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

Я в данном случае выступаю и заказчиком.

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

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

Если бы оптимизация была нужна, я бы это делал сразу.

Тогда зачем доказывать, что в плане эффективности и производительности разницы нет? Ещё и о ассемблере речь.

Если речь идет об астрактной работе со строками и их объединением в памяти то реализация на ассемблере с большой вероятностью будет работать быстрее реализации на java.

Но в данном то конкретном случае мы имеем условия, близкие к граничным, когда цикл выполнится 1 раз, и может когда-нибудь 2 раза. Соответственно ответ уже будет другой, скорее всего что будет одинаково для 1 раза.

Итог - говнокод в коде не найден для имеющихся условий, или еще хочешь обсудить какой-то участок?

Речь идет не о java vs assembler, а о StringBuilder vs "+" in StringBuilder.