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

    +73

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    12. 12
    13. 13
    14. 14
    15. 15
    16. 16
    17. 17
    18. 18
    19. 19
    20. 20
    21. 21
    22. 22
    public boolean isModified() {
	return
			!pluginEnabled.isSelected() == getSettings().pluginEnabled
					|| !pathToContainerTextField.getText().equals(getSettings().pathToProjectContainer)
					|| !pathToUrlGeneratorTextField.getText().equals(getSettings().pathToUrlGenerator)
					|| !symfonyContainerTypeProvider.isSelected() == getSettings().symfonyContainerTypeProvider
					|| !objectRepositoryTypeProvider.isSelected() == getSettings().objectRepositoryTypeProvider
					|| !objectRepositoryResultTypeProvider.isSelected() == getSettings().objectRepositoryResultTypeProvider

					|| !twigAnnotateRoute.isSelected() == getSettings().twigAnnotateRoute
					|| !twigAnnotateTemplate.isSelected() == getSettings().twigAnnotateTemplate
					|| !twigAnnotateAsset.isSelected() == getSettings().twigAnnotateAsset
					|| !twigAnnotateAssetTags.isSelected() == getSettings().twigAnnotateAssetTags

					|| !phpAnnotateTemplate.isSelected() == getSettings().phpAnnotateTemplate
					|| !phpAnnotateService.isSelected() == getSettings().phpAnnotateService
					|| !phpAnnotateRoute.isSelected() == getSettings().phpAnnotateRoute
					|| !phpAnnotateTemplateAnnotation.isSelected() == getSettings().phpAnnotateTemplateAnnotation

					|| !yamlAnnotateServiceConfig.isSelected() == getSettings().yamlAnnotateServiceConfig
			;
}

    Плагин для Intellij Idea...

    Запостил: kostoprav, 28 Июня 2013

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

    • ava Int 28.06.2013 12:15 # 0

      Ну ведь != — не красивенько
      Ответить

      • ava inkanus-gray 28.06.2013 12:20 # +4

        Не спорю, в других языках есть знак <>, он красивее. Однако, отношения «меньше» и «больше» определены только в метрических пространствах, поэтому приходится терпеть !=.

        И да, в данном коде != не нужно, поскольку есть законы де Моргана.
        Ответить

        • ava guest 28.06.2013 18:57 # +4

          Отношения "больше" нет - это лишь shortcut для "не (меньше или равно)". Отношение "меньше" тоже нет - это shortcut для "не (меньше или равно) и не (совпадают)". Отношение "меньше или равно" определено в частично упорядоченных множествах, которые не имеют с метрическими пространствами ничего общего.
          Ответить

          • ava inkanus-gray 28.06.2013 20:29 # 0

            Спасибо. Всё верно, насчёт метрики я написал глупость.
            Ответить

          • ava guest 05.07.2013 18:17 # 0

            >>не (меньше или равно) и не (совпадают)
            хуйню написал
            Ответить

    • ava inkanus-gray 28.06.2013 12:32 # +1

      Ну и страшная же эта Java. В сишечке можно было бы просто пройтись в цикле указателем по полям.
      Ответить

      • ava kostoprav 28.06.2013 12:36 # +1

        Ну в Java через reflection так тоже можно сделать. Меня кроме этого еще тонна вещей смущает... К примеру getSettings() явно можно вызвать один раз... JIT JIT'ом, но не надо же так издеваться.
        Ответить

      • ava roman-kashitsyn 28.06.2013 12:36 # +4

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

        Я так понимаю, здесь сравнивают состояние UI с конфигом, чтобы понять, были реальные изменения (т.е. не "подёргивания") или нет.

        Объекты разнородные, мне вот сложно более удобную схему придумать. Чейндж-листенеры не аналогичны, ибо они не смогут распознать "подёргивания".
        Ответить

        • ava defecate-plusplus 28.06.2013 12:41 # +6

          http://соснули.рф
          Ответить

        • ava inkanus-gray 28.06.2013 13:08 # 0

          Виноват, не заметил, что там методы, а не поля. А так хотелось сделать по-царски что-нибудь типа while (*p++ == *q++) ++i;
          Ответить

          • ava roman-kashitsyn 28.06.2013 13:15 # +3

            Да даже если и поля. Если поля разных типов, а они обычно разных типов, то вот так просто по ним не пройдёшь. Во вторых, если поля лежат в структуре, указателем по ним проходить обычно нельзя, ибо компилятор волен оставлять в них дырки удобного ему размера.
            Ответить

            • ava inkanus-gray 28.06.2013 13:17 # +4

              Вменяемые компиляторы ничего не должны вставлять, потому что Царю так неудобно.
              Ответить

              • ava roman-kashitsyn 28.06.2013 13:34 # +6

                Царь использует только целые числа и массивы, всё остальное - уделел анскильных питушков
                Ответить

        • ava someone 28.06.2013 15:17 # 0

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

          Всё правильно. Тут одним сравнением не отделаешься.

          Если бы были объекты одного типа, можно было бы сделать EqualsBuilder.reflectionEquals.

          А вообще я использую Lombok, и там есть @EqualsAndHashCode (а ещё @Getter, @Setter, @ToString и @Data). И это хорошо.
          Ответить

    • ava Lure Of Chaos 28.06.2013 13:40 # 0

      а по мне, здесь вообще не должно быть такой проверки. а вот должно быть поле modified, значение которого и должно этим методом возвращаться. а все изменения его происходить в методах setSelected(), или, если стандартные контролы, то в обработчиках событий изменения. а сбрасываться этот флаг должен в методе, откуда сабж вызывается или в методе "сохранения" конфигурации.
      Ответить

      • ava kostoprav 28.06.2013 13:49 # 0

        Ну это сложнее, надо отслеживать "подергивания" и помнить, что сброс одного поля на значение в конфиге может и не сбросить флаг модификации. Тогжа уж скорее modified будет битовой маской, равенство которой нулю означает отсутсвие изменений.
        Ответить

        • ava Lure Of Chaos 28.06.2013 14:13 # 0

          отслеживать "подергивания" как раз в месте изменения modified
          и все равно от "длинных" "подергиваний" не спасет (когда 3е состояние не равно 2ому, но равно уже "забытому" 1ому)
          ну и имхо это ничего страшного.
          Ответить

          • ava kostoprav 28.06.2013 14:22 # 0

            Ну как бы если в методе setA() сделать что-то в духе:

            if (config.a == this.a) {
  setANotModified(); // Здесь магия с флагами масками и т.д.
} else {
  setAIsModified();
}


            То спасать должно... Или я не прав?
            Ответить

            • ava Lure Of Chaos 28.06.2013 15:18 # 0

              должно быть, только маски вроде и не нужны, просто признак - отличается от предыдущего состояния (до момента обновления) или нет.
              не будете же вы хранить всю историю изменений. да и даже если будете, то как определите, где подергивание, а где желаемое состояние?
              Ответить

              • ava kostoprav 28.06.2013 15:23 # 0

                В принципе - да, но этот признак должен уметь обработать следующий сценарий:

                - меняем А, признак устанавливается
                - меняем Б, признак установлен
                - возвращаем А назад - вот тут важно понять, что признак должен остаться установленным...

                Поэтому я и предложил битовую маску
                Ответить

    • ava wvxvw 28.06.2013 14:51 # 0

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

      ЗЫ.
      (every (lambda (a b) (string= (observed-method a) b))
     (list object-a object-b object-c ... object-x)
     (list setting-a setting-b ... setting-x))
      Ответить

      • ava kostoprav 28.06.2013 14:52 # +1

        Мне кажется, ответ кроется в адресе этого сайта...
        Ответить

    • ava anonimb84a2f6fd141 30.06.2013 19:25 # −3

      Автор был под крокодилом, хз
      Ответить

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