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

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

        И да, в данном коде != не нужно, поскольку есть законы де Моргана.
        Ответить
        • Отношения "больше" нет - это лишь shortcut для "не (меньше или равно)". Отношение "меньше" тоже нет - это shortcut для "не (меньше или равно) и не (совпадают)". Отношение "меньше или равно" определено в частично упорядоченных множествах, которые не имеют с метрическими пространствами ничего общего.
          Ответить
          • Спасибо. Всё верно, насчёт метрики я написал глупость.
            Ответить
          • >>не (меньше или равно) и не (совпадают)
            хуйню написал
            Ответить
    • Ну и страшная же эта Java. В сишечке можно было бы просто пройтись в цикле указателем по полям.
      Ответить
      • Ну в Java через reflection так тоже можно сделать. Меня кроме этого еще тонна вещей смущает... К примеру getSettings() явно можно вызвать один раз... JIT JIT'ом, но не надо же так издеваться.
        Ответить
      • > В сишечке можно было бы просто пройтись в цикле указателем по полям
        щас, ага.

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

        Объекты разнородные, мне вот сложно более удобную схему придумать. Чейндж-листенеры не аналогичны, ибо они не смогут распознать "подёргивания".
        Ответить
        • http://соснули.рф
          Ответить
        • Виноват, не заметил, что там методы, а не поля. А так хотелось сделать по-царски что-нибудь типа while (*p++ == *q++) ++i;
          Ответить
          • Да даже если и поля. Если поля разных типов, а они обычно разных типов, то вот так просто по ним не пройдёшь. Во вторых, если поля лежат в структуре, указателем по ним проходить обычно нельзя, ибо компилятор волен оставлять в них дырки удобного ему размера.
            Ответить
            • Вменяемые компиляторы ничего не должны вставлять, потому что Царю так неудобно.
              Ответить
              • Царь использует только целые числа и массивы, всё остальное - уделел анскильных питушков
                Ответить
        • > В сишечке можно было бы просто пройтись в цикле указателем по полям
          > Объекты разнородные, мне вот сложно более удобную схему придумать.

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

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

          А вообще я использую Lombok, и там есть @EqualsAndHashCode (а ещё @Getter, @Setter, @ToString и @Data). И это хорошо.
          Ответить
    • а по мне, здесь вообще не должно быть такой проверки. а вот должно быть поле modified, значение которого и должно этим методом возвращаться. а все изменения его происходить в методах setSelected(), или, если стандартные контролы, то в обработчиках событий изменения. а сбрасываться этот флаг должен в методе, откуда сабж вызывается или в методе "сохранения" конфигурации.
      Ответить
      • Ну это сложнее, надо отслеживать "подергивания" и помнить, что сброс одного поля на значение в конфиге может и не сбросить флаг модификации. Тогжа уж скорее modified будет битовой маской, равенство которой нулю означает отсутсвие изменений.
        Ответить
        • отслеживать "подергивания" как раз в месте изменения modified
          и все равно от "длинных" "подергиваний" не спасет (когда 3е состояние не равно 2ому, но равно уже "забытому" 1ому)
          ну и имхо это ничего страшного.
          Ответить
          • Ну как бы если в методе setA() сделать что-то в духе:

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


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

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

                Поэтому я и предложил битовую маску
                Ответить
    • А почему вся эта хрень не может заимплементить какой-нибудь 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))
      Ответить
      • Мне кажется, ответ кроется в адресе этого сайта...
        Ответить
    • Автор был под крокодилом, хз
      Ответить

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