1. Java / Говнокод #14510

    +68

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    public static String elvis(String value, String ifNull) {
            return value == null ? ifNull : value;
        }
    
        public static Boolean elvis(Boolean value, Boolean ifNull) {
            return value == null ? ifNull : value;
        }
    
        public static Object elvis(Object value, Object ifNull) {
            return value == null ? ifNull : value;
        }

    - Objects#firstNotNull()?
    - нет, не слышал

    Запостил: myzone, 05 Февраля 2014

    Комментарии (34) RSS

    • минуснул. потому что Элвиса плюсовать это грех.
      Ответить
    • О дженериках автор, видимо, тоже не слышал.
      Ответить
    • > Objects#firstNotNull()
      Внешняя зависимость же... Не всегда айс. Или там guava/commons уже юзается?
      Ответить
      • Если не стоит ограничение "никаких внешних зависимостей", то отказываться от гуавы бессмысленно. Самая адекватно спроектированная либа для жабы из всех, что я видел.
        Ответить
        • Вот если бы ещё обратносовместимость была на уровне, а то её грамотность привносящая популязиционный фактор, приводит к адовому jar hell от зависимостей в третьем колене.
          Ответить
          • jar hell happends не хороших дипендерсов, так что лишний повод избавиться от аудейтед хлама ;)
            Ответить
            • Порой аутдейтед хлам является основополагающей либой "от партнёров".
              Ответить
              • Уходите вы оттуда...
                Ответить
                • Не надо паники. Тешит то, что этвсёхерня в сравнении со стыковкой с тем тырпрайзом, который крутится на старопне под мсдосом. А переписывать никто софт не собирается ибо оно "и так хорошо работает".
                  Ответить
          • Можно поподробнее? Где не соблюдается обратная совместимость?
            Ответить
            • Да пожалуйста, http://docs.guava-libraries.googlecode.com/git-history/release/jdiff/changes.html. Туева хуча @Deprecated режется в следующих релизах, чем доставляет попаболь от необходимости использования разных класслоадеров для библиотек, зависимых от разных версий гуавы или же подключать м'OSGi.
              Ответить
      • Гуавы там не было, а зря...
        Там люди сделали NativeStringCache, например, кто догадается как он работает?
        Ответить
        • String.intern()?
          Ответить
          • Правильно!
            Ответить
            • Зато потом через == можно сравнивать :) Темная сторона силы.
              Ответить
              • Только с 1.7. Там уже не в пермгене хранится.
                Ответить
                • А в 1.6 и ниже через == разве нельзя сравнивать?

                  Или ты о сборке мусора из пула интернированных строк?
                  Ответить
                  • >о сборке мусора из пула интернированных строк
                    OutOfMemoryError: PermGen space error
                    Это сильно заябывает. А куча больше.
                    Ответить
                • кстати, там в этом коде рефлексией брался филд "offset" из стринга и мутились "указатели" на эти строки, или что-то типа того, я не сильно заморачился логикой, ибо наш проект переехал на последний релиз JDK, а там стринг перепилили :D
                  Ответить
              • Да, если только перед сравнением строки уже не надо интернировать, а то equals поди дешевле будет интернирования.
                Ответить
                • Нихера подобного.
                  Интернируем - раз при создании, как и расчёт хеш-кода. А equals нужно много раз на немутабельном объекте (те же мапы, они везде).

                  Если конечно строки не одноразовые, типа такого гогна:
                  while(it.hasNext()) s+=it.next();

                  Короче от контекста зависит.
                  Ответить
                  • Кому что...
                    Ответить
                    • Спасибо за минус. Я стану стражем твоей тени. (LEXX, надеюсь, смотрели)
                      Ответить
                  • Я не понял, что тут нихера. Вот в пример, о чём я выше писал, что менее накладнее, internedString == userString.intern() или internedString.equals(userString)? Контекст тут такой, юзер ввёл своё имя и мы проверяем, не "олень" ли юзер.
                    Ответить
                    • Далее ссылка на строку с именем пользователя может путешествовать по системе и попадать в разные мапы, дабы доставать разную инфу.
                      Ответить
                      • Получается, что например, если путешествие занимает 10 мап в роли ключа, то мы экономим >= 10 полных String.equals, в зависимости от коллизий. Оптимизация, однако!
                        Ответить
        • Ну неужели через JNI, раз native?
          Ответить

    Добавить комментарий