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

    +94

    1. 1
    2. 2
    3. 3
    4. 4
    5. 5
    @Override public int hashCode()
        {
            int hash = 7;
            return hash;
        }

    Ну это явно хит!

    Запостил: dwinner, 06 Ноября 2011

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

    • int random() { return 4; }
      Т.е. [:||||||:]
      Ответить
      • Не, немного не то, но близко.
        А прикинь, случайное число в качестве хэша?
        Ответить
        • @Override
          public int hashCode() {
              return random();
          }
          
          private int random() {
              return 4;
          }
          Ответить
    • показать все, что скрытокод-говно, автор-мудак
      Получил поиск в HashMap за O(n).
      Ответить
      • показать все, что скрытосначала пиши, потом подписывайся. не наоборот.
        fix: O(1)
        Ответить
        • с одним хешкодом на все элементы?
          именно О(n)
          fixed
          Ответить
          • >>Получил поиск в HashMap за O(n).
            хеш один на всех ->  в мапе не больше одного элемента -> константное время
            Ответить
            • Вон почитай, roman-kashitsyn тоже самое говорит:
              http://govnokod.ru/8431#comment117904
              , если сам додуматься не в состоянии
              Ответить
              • да, я ошибся.
                в хешмапе итемы с одним хешем чейнятся, что значит O(n).
                Ответить
      • Год - гавно говоришь?! Вот уж никогда бы не подумал... Ну а сайт-то как называется?! :-)
        Ответить
      • То, что сортировка и поиск в коллекциях для данных объектов отработает неправильно - очевидность!
        А, ну точно. Надо ж похвалиться, что вы типа знаете, как-то сразу не подумал... Sorry
        Ответить
        • >То, что сортировка и поиск в коллекциях для данных объектов отработает неправильно - очевидность!
          Сортировка отработает правильно, поиск - тоже. Медленно, правда, искать будет.

          >очевидность!
          Как видно, для тебя это оказалось не очевидным.
          Ответить
          • Следуя вашей логике: медленно и правильно это синонимы?
            Ответить
            • ошибки в реализации алгоритма нет. реализация алгоритма будет выдавать верные результаты работы, пусть и с намного более низкой скоростью
              Ответить
              • показать все, что скрытоСогласен. Не те слова использовал... Тем не менее хэш-конфликты при каждой попытке упорядочивания HashMap'ов, TreeMap'ов... есть ошибка, хоть JVM об этом ничего "не говорит". Утечка памяти - менее очевидная проблема... Про недостижимые участки памяти в куче JVM тоже молчит, а GC ничем помочь не может, и всё же это ошибка, допущенная (с высокой степенью вероятности) разработчиком. Может быть я не совсем точно подобрал для этого всего слово "Ошибка"...
                Ответить
                • по-моему, вы какую-то херню несёте
                  Ответить
                  • Чтоб элемент в хэш-таблицу вставить вычисляется хэш-код, потом делится на общее кол-во ячеек. Полученное число - номер ячейки. Если такой номер есть, возникает хэш-конфликт. Вставка, сортировка - это же модификация?! В чем же херня?
                    Ответить
                    • Сортировка хэш-таблицы - конечно, херня. А конфликты - дело обычное, они возникают при любом определении хэш-кода.
                      А когда вы начали вещать о мемори-ликах, JVM и GC у меня сложилось вмечатление, что вы просто перечисляете знакомые слова.
                      Ответить
                      • Сортировка хэш-таблицы - херня, согласен, лучше списки использовать, ОКЭ!
                        Ответить
                      • >Сортировка хэш-таблицы - конечно, херня
                        А между тем, есть контейнеры, правда в стандартных библиотеках я их ни разу не видел, снижающие максимальную сложность поиска в хештаблице О(n/k) до О(log(n/k)) (k=размер хештаблицы=const) при условии правильно подобранной хешфункции или О(n) до О(log(n)) при неправильно подобранной хешфункции. А именно за счет сортировки колизиирующих элементов в одном элементе хештаблицы. То есть для таких контейнеров, даже если написать такую хешфункцию, как написал автор этого говнокода, то он все равно получает поиск О(log(n)), а не О(n).
                        Ответить
                        • Для этого, наверное, списки нужно заменить деревьями и требовать наличия строгого отношения порядка для хранимых элементов
                          Ответить
                          • Мне кажется, это будет медленнее из-за константы.
                            Ответить
                            • Да, лучше уж таблицу побольше сделать и функцию хэширования хорошую подобрать
                              Ответить
                              • >Да, лучше уж таблицу побольше сделать
                                Кстати, не видел я что-то в C# для Dictionary параметра размера хештаблицы k. Он там регулируется как-нибудь?
                                Ответить
                                • не знаю, как в C#, а в Java в конструкторе HashMap есть параметр loadFactor, при достижении которого у HashMap'ы случится resize
                                  Ответить
                                • разумеется, есть ещё параметр initialCapacity для задания начального k
                                  Ответить
                            • >Мне кажется, это будет медленнее из-за константы.
                              Можно поподробнее?
                              Ответить
                              • Что подробнее? Если k достаточно большое, то разница между n/k и log(n/k) окажется слишком мала, чтобы перекрыть проигрыш от возни с деревом.
                                Ответить
                                • Ну, это само собой, в таких случаях этот контейнер и не используют. Используют тогда, когда хешфункцию правильно подобрать тяжело.
                                  Ответить
                        • Обычно стараются поддерживать k > n.
                          Ответить
                  • public class Stack
                    {
                    private Object[] elements;
                    private int size = 0;
                    private static final int DEFAULT_INITIAL_CAPACITY = 16;

                    public Stack()
                    {
                    elements = new Object[DEFAULT_INITIAL_CAPACITY];
                    }

                    public void push(Object e)
                    {
                    ensureCapacity();
                    elements[size++] = e;
                    }

                    public Object pop()
                    {
                    if (size == 0)
                    throw new EmptyStackException();
                    return elements[--size];
                    }

                    private void ensureCapacity()
                    {
                    if (elements.length == size)
                    elements = Arrays.copyOf(elements, 2 * size + 1);
                    }
                    }

                    Код компилится, но память течет... Тоже что ли херня?! Мож я просто не понимаю значения слова херня?! )))
                    Ответить
                    • Бля, я тоже Блоха читал, только тут это совершенно не при чём.
                      Ответить
                      • Слова конечно знакомые... Но я ж про ошибки веду дилемму, про концептуальные ошибки, кстати слово "концептуальные" тоже где-то слышал, какое совпадение...
                        Ответить
        • Сортировка и hash-код вещи в каком-то смысле противоположные. Такое определение hash-код ничего не сломает, разве что поиск элементов будет медленным (как уже сказал XXXGovno), поскольку хэш-код будет давать плохое распределение экземпляров. Правильная сортировка же достигается имплементацией Comparable или определением Comparator'а.
          ваш К.О.
          Ответить
    • а оно вообще используется?
      Ответить
    • Лёгким движением руки хэш-таблица превращается... в список.
      Ответить
    • А вдруг это hashCode для уникального иммутабельного объекта 0_o
      Ответить
      • Нет, хотя было бы забавно. Это сгенерил NetBeans, я в спешке поля не указал, не сразу заметил...
        Ответить
    • >Ну это явно хит!
      http://gorod.tomsk.ru/uploads/31604/1236156756/50.jpg
      Ответить
    • // The worst possible legal hash function - never use! (c) Effective JavaTM Second Edition
      Ответить

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