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

    +90

    1. 1
    2. 2
    3. 3
    4. 4
    5. 5
    6. 6
    7. 7
    8. 8
    @Override
    public Object clone() {
              try {
                            return super.clone();
    	        } catch (Exception e) {
    			return this;
    		}
    }

    "Клонирование"

    Запостил: auf1r2, 21 Июля 2011

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

    • super.clone(); - от Object'a
      Ответить
    • > return this;
      ёкарный бабай!
      Ответить
    • "Сравнение" из того-же класса :)

      @Override
      public int compareTo(Info i) {
      	if (i.distance == distance)
      		return 0;
      	else if (i.distance < distance)
      		return 1;
      	else return -1;
      }


      equals и hashCode нет вообще
      Ответить
      • в принципе правильно - хоть и можно было обойтись вычитанием
        Ответить
        • А если сравниваемый Info == null ?
          Ответить
          • А сорри, ступил сам, это в equals null дает значение false
            Ответить
          • javadoc пишет: http://download.oracle.com/javase/1.4.2/docs/api/java/lang/Comparable.html
            Note that null is not an instance of any class, and e.compareTo(null) should throw a NullPointerException even though e.equals(null) returns false.
            то есть, так и нужно.
            Ответить
        • Насчет вычитания. Для int и long нельзя.
          Ответить
          • ?
            Ответить
            • Если из Integer.MAX_VALUE вычесть Integer.MIN_VALUE получим -1
              Ответить
              • практически значение вряд ли будет Integer.MAX_VALUE или Integer.MIN_VALUE
                Ответить
                • Согласен, что вряд ли будет. Однако случаи бывали.

                  Из этой же серии "проверка на нечетность".

                  public boolean isOdd(int value) {
                  return value % 2 == 1;
                  }
                  Ответить
              • В нормальных языках существует контроль за целочисленным переполнением.
                Ответить
                • Открою тайну - "нормальных" языков не бывает =)
                  Ответить
                  • Ты не веришь, что есть языки с контролем целочисленного переполнения? В сишкомирке (и во всём, что сделано похожим на говНяшку, включая жабу) таких действительно нет.
                    Ответить
                    • Ты веришь, что "контроль целочисленного переполнения" делает язык нормальным? Может назовешь "нормальный" язык?
                      Ответить
                      • Я верю, что его отсутствие делает язык ненормальным. Условие необходимое, но не достаточное.
                        Ответить
                        • Так может назовешь "нормальный" язык?
                          Ответить
                          • Нормальные по данному критерию? Да, могу.
                            Отсутствие проверки переполнения не оправдано ничем.
                            Ответить
                            • А есть языки "нормальные" по всем критериям?
                              Ответить
                            • TarasB, не могли бы вы все-таки ответить на вопрос "есть ли языки нормальные по всем критериям"?
                              Ответить
                              • это противоречивое требование
                                Ответить
                              • есть нормальный Ruby, но он страшен в синтаксисе и неповоротлив
                                есть нормальный Python, но whitespace там имеет значение и синтаксис
                                есть нормальная Java, но медленная и в песочнице
                                есть нормальные С\С++, но сложные и остальными низкоуровневыми заморочками
                                Ответить
                                • есть нормальный Haskell, чтоб на нём писать, нужно сперва напиться
                                  есть нормальный Lisp, но он в деды нам всем годиться

                                  предлагаю собрать всё вместе, доработать и сочинить песенку.
                                  Ответить
                              • Нет, так как это требование противоречиво (ответили выше). Но некоторые требования не противоречат остальным. Например, контроль переполнения, контроль выхода за диапазон (в паскалоидных это одно и то же). И скорости это не противоречит, так как эти проверки отрубаются директивами компилятора.
                                А это значит, что языки, не удовлетворяющие этим требованиям - ацтой.
                                Ответить
                                • >И скорости это не противоречит, так как эти проверки отрубаются директивами компилятора

                                  1. В твоем нормальном языке по умолчанию выключен контроль переполнения. Когда он тебе нужен ты ставишь директивы компилятору. В java: используется int, когда нужен контроль используем BigInteger.
                                  2. В твоем нормальном языке по умолчанию включен контроль переполнения. Когда он не нужен ты ставишь директиву. В java: используется BigInteger, с откатом до int в случае необходимости.

                                  Итог: один хер приходится следить за переполнением. Только ты ставишь директиву компилятора, а жава-кодеры применяют другой тип.

                                  > это значит, что языки, не удовлетворяющие этим требованиям - ацтой
                                  Это уже диагноз =) Ты тут наверное любимчик =)
                                  Ответить
                                  • > В твоем нормальном языке по умолчанию включен контроль переполнения.

                                    Да, именно так.

                                    > В java: используется BigInteger

                                    Кем? Видишь ли, в нормальном языке надо делать лишние движения, чтобы отрубить проверки, а в ненормальным - надо делать движения, чтобы включить.

                                    > Только ты ставишь директиву компилятора, а жава-кодеры применяют другой тип.

                                    Поменять директивы легче, чем поменять тип.
                                    Ответить
                                    • > Кем? Видишь ли, в нормальном языке надо делать лишние движения, чтобы отрубить проверки, а в ненормальным - надо делать движения, чтобы включить.

                                      Прикольно обсерать языки, которых не знаешь? BigInteger не проверяет на переполнение, он позволяет работать с числами с произвольной точностью, как Integer в Haskell (где для обычных чисел "с переполнением" есть Int). Python и Lisp при возможности переполнения сами обернут целое число в аналогичную обёртку. Директива компилятора же не сделает целочисленный тип шире. Ну, быть может, уронит программу в случае переполнения. Как видишь, разница принципиальна.
                                      Ответить
                                      • > BigInteger не проверяет на переполнение, он позволяет работать с числами с произвольной точностью

                                        Я понял.

                                        > Директива компилятора же не сделает целочисленный тип шире.

                                        Я в курсе. Это твой коллега посоветовал BigInteger в качестве решения. Пойми одну вещь - облажаться из-за того, что ЗАБЫЛ включить проверку/широкий тип итд, намного легче, чем облажаться из-за того, что СОЗНАТЕЛЬНО ОТКЛЮЧИЛ проверку.
                                        Ответить
                                  • Да хватит ужо типом в класс тыкать.
                                    Ответить
                                  • > В твоем нормальном языке по умолчанию включен контроль переполнения. Когда он не нужен ты ставишь директиву.

                                    Представляется сразу суровый кодер на Ада, который перед релизом втыкает/вырезает в 1.500.000 строках кода директивы компилятора для отключения/включения проверок... Надеюсь, у компилятора и для этого есть опция )
                                    Ответить
                                    • Виден опыт языков без директив, да.
                                      Во-первых, можно отрубить во всём проекте. Можно отрубить в модуле. Можно найти узкое место (одну функцию) и отрубить только в ней.
                                      Ответить
                    • В C++ есть тип SafeInteger в либе от Intel с контролем целочисленного переполнения
                      Ответить
                      • Чтобы сделать программу безопасной, надо во всём коде типы поменять?
                        По умолчанию язык навязывает именно опасный тип, что очень плохо.
                        Ответить
                • И что делает "нормальный" язык при возникновении переполнения? Так и вижу сhecked OverflowException, который нужно отлавливать при каждой операции с целым числом. Представляю также, как "быстро" работает код, требующих большого числа вычислений, когда при каждой арифметической операции проверяются регистры OF и CF... Вы, батенька, сразу видно, не практик и воспитаны на паскальной живописи.
                  Ответить
                  • >сhecked OverflowException
                    круто.

                    а на каждую мало-мальски значимую операцию.
                    например объявление перменной нужно ввести checked OutOfMemoryException.

                    Тарас просто любитель переусложненной и тяжеловесной Ады, которая не делает код надеждней, а только усложняет и тормозит его.
                    Ответить
                    • показать все, что скрыто> которая не делает код надеждней, а только усложняет и тормозит его.

                      Ты меня прям затроллил этой фразой, я аж почувствовал БАТТХЁРТ и заминусовал твой коммент.
                      Ответить
                  • Ты вообще в курсе про директивы компилятора, возможность локально отрубать проверки, а?
                    Ответить
                    • В курсе. К счастью, в Java их нет. Ваши выпадки против C и Java неубедительны и смешны. А вы, скорее всего, промышленному программированию отношения не имеете. Учите дальше школьников вычислять палиндромы. Не разводите холивары и не мешайте людям глумиться над промышленным говном. Пожалуйста.
                      Ответить
                      • > В курсе

                        Тогда весь твой предыдущий пост - необоснованное гонево.

                        > К счастью, в Java их нет.

                        Обоснуй. Твой предыдущий пост - слив, не считается.

                        > А вы, скорее всего, промышленному программированию отношения не имеете.

                        Если тебя устраивают баги из-за целочисленного переполнения, то не тебе судить мою компетентность.

                        > Учите дальше школьников вычислять палиндромы. Не разводите холивары и не мешайте людям глумиться над промышленным говном. Пожалуйста.

                        Не учи меня, что мне делать. Пожалуйста.Ты слишком глуп для этого, в тебе слишком много агрессии на Паскаль.
                        Ответить
                        • >Обоснуй. Твой предыдущий пост - слив, не считается.
                          КАК Вы собираетесь решить проблему переполнения в методе compareTo() при помощи, предположим, директив? В любой нормальной книжке по java проблема переполнения упоминается (взять, хотя бы, CoreJava), и единственная мера борьбы с ней - использование условных операторов. Проверка на нечётность легко проверяется побитовыми операциями.
                          >Если тебя устраивают баги из-за целочисленного переполнения, то не тебе судить мою компетентность.
                          Меня не устраивают любые баги, нужно просто уметь избегать подобных ошибок. Язык тут не при чём, если причина в физике.
                          > Ты слишком глуп для этого, в тебе слишком много агрессии на Паскаль.
                          Во мне нет агрессии к паскалю, ибо язык довольно строен и богат, у меня отвращение к его проповедникам, поливающим гавно на мэйнстрим. Кстати, Никлаус Вирт считал Аду, мягко говоря, кровавым выпердышем.
                          Ответить
                          • В прочем, по поводу C и Java Никлаус примерно такого же мнения. )
                            Ответить
                          • > и единственная мера борьбы с ней - использование условных операторов

                            Ну так и пиши условные операторы!

                            > Меня не устраивают любые баги, нужно просто уметь избегать подобных ошибок. Язык тут не при чём, если причина в физике.

                            Язык должен предоставлять средства от подобных ошибок. Если создатели языка не осилили встроить проверку на переполнение, то это большой МИНУС языка, и как ни отмазывайся, это будет МИНУС.

                            > Во мне нет агрессии к паскалю
                            > Представляю также, как "быстро" работает код, требующих большого числа вычислений, когда при каждой арифметической операции проверяются регистры OF и CF... Вы, батенька, сразу видно, не практик

                            Ну да, ну да...

                            > Кстати, Никлаус Вирт считал Аду, мягко говоря, кровавым выпердышем.

                            Слово "выпердыш" уже ты вставил. Скажи ещё, "хероподгандонным захуищем", чтобы ещё красочнее было!
                            Так вот, в 83 году Ада казалась сложной, да, но это был 83 год, С++ в нынешнем виде ещё не было.
                            И мнение Вирта нельзя считать объективным, так как он тоже участвовал в том конкурсе на военный язык и пролетел.
                            Ответить
                            • > Ну так и пиши условные операторы!
                              Таки пишу, товарищ, пишу. А когда реально нужна арифметика без переполнения (допустим, операции с финансами), использую стандартные классы BigInteger и BigDecimal, реализующие операции над числами с произвольной точностью без переполнения.

                              >Слово "выпердыш" уже ты вставил
                              А я вроде quote и (c) нигде не ставил.

                              Дискуссия себя явно исчерпала. Прощайте, сударь.
                              Ответить
                              • Скатертью дорога.
                                Ответить
                              • правильно не надо его кормить и так уже ожирение IV степени
                                Ответить
                                • Кстати, есть немного. Из-за жира уже кубики пресса иногда плохо видны.
                                  Нездоровый образ жизни у меня какой-то.
                                  Ответить
                            • >в 83 году Ада казалась сложной, да, но это был 83 год, С++ в нынешнем виде ещё не было.

                              Ох лол. Тут с Тарасом не поспоришь, да.
                              Ответить
      • Это нормально. Если нужно всего лишь отсортировать массив. И в TreeSet/TreeMap использовать иногда можно. Тем более, что класс, судя по всему, внутренний.
        Ответить
    • показать все, что скрытоvanished
      Ответить

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