Для объединения двух условий используйте IF или EVALUATE в COBOL? - PullRequest
1 голос
/ 01 декабря 2011

«Если это работает, не трогай это» ... Я понимаю.Тем не менее, код, который я расширяю, усеян блоками, подобными этому:

 EVALUATE TRUE ALSO TRUE
  WHEN FOO-YES ALSO BAR-YES
   PERFORM ACTION
  WHEN OTHER
   SET ERROR TO TRUE
 END-EVALUATE

На мой неопытный взгляд, IF кажется более ясным:причина предпочесть ОЦЕНИТЬ, чем ЕСЛИ?

Ответы [ 4 ]

2 голосов
/ 01 декабря 2011

Нет причин предпочитать ОЦЕНИВАТЬ, чем ЕСЛИ. Да, но у меня нет веских причин для этого. Я пытаюсь закодировать, чтобы сопровождающему было легко понять, но будут случаи, когда логика сложна, и вы в итоге получите такие конструкции, как ...

EVALUATE TRUE ALSO TRUE ALSO TRUE
  WHEN INITIAL-STATE ALSO ANY ALSO ANY 
       PERFORM 0100-INITIALIZE
       PERFORM 1000-DISPLAY-MENU
  WHEN MENU-DISPLAYED ALSO DFHRESP(NORMAL) ALSO UPDATE-REQUESTED
       PERFORM 2000-DO-THE-UPDATE
       EXEC CICS RETURN END-EXEC
  [...and so forth...]
END-EVALUATE

Где-то есть цитата о том, как все должно быть максимально просто, но не проще. Есть, конечно, много способов закодировать ту же логику. Разные люди находят разные конструкции проще для понимания. Из-за этих различий возникает множество аргументов.

2 голосов
/ 01 декабря 2011

Вы правильно прочитали.«True ALSO True» - очень странная вещь для кода.

Часто вы увидите «Evaluate True», и в этом случае условия когда все действуют ТОЧНО, как операторы IF.Использование ТАКЖЕ вводит некоторые возможные странности, поскольку это не так, как операторы CASE из всех других языков.

Хороший способ написать это:

Evaluate true
  when FOO-YES and BAR-YES
    perform action
  when other 
    set error to true
End-Evaluate

Конечно, ИСТИНА ТАКЖЕИСТИНА очень легко понять, но вы могли бы ИСТИННО ТАКЖЕ WS-BLAH-BLAH, и это может привести к путанице.Глагол Cobol Evaluate очень мощный, и иногда легко выстрелить себе в ногу.Тем не менее, он очень мощный и позволит вам много делать.

Часто бывает так, что запутанные IF, которые не гнездятся чисто, могут быть исправлены с помощью хорошо написанного Evaluate.

0 голосов
/ 14 марта 2012

Для меня все сводится к удобочитаемости (и, следовательно, к более простому обслуживанию в дальнейшем).

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

За 22 года программирования на Cobol я никогда не использовал ALSO в EVALUATE.И использование блока EVALUATE для простого бинарного теста истина / ложь кажется мне немного тупым.

Но не поймите меня неправильно, я люблю EVALUATE s при правильном использовании.Когда я начал программировать на Java 6 лет назад, мне больше всего не хватало EVALUATE.Конечно, у Java есть switch, но его нельзя использовать так же гибко, как EVALUATE.

Рассмотрим следующий сегмент кода:

IF ACTION = "START"
   PERFORM START
ELSE IF ACTION = "STOP"
   PERFORM STOP
ELSE IF ACTION = "PROCESS" AND FILE-NAME = "A"
   PERFORM PROCESS-A-FILE
ELSE IF ACTION = "PROCESS" AND FILE-NAME = "B"
   PERFORM PROCESS-B-FILE
ELSE IF ACTION = "RESET"
   PERFORM RESET
ELSE
   PERFORM INVALID-ACTION-ERROR.

Этот набор операторов IFесть некоторые реальные проблемы.Не добавляя 5 END-IF s к его концу, вы должны завершить блок с полной остановкой.Но вы бы не смогли этого сделать, если бы, скажем, код был внутри блока PERFORM UNTIL ... END-PERFORM.Хотя этот пример довольно прост, в более сложном (и более длинном) примере было бы сложно определить, с каким ELSE идет, а с каким IF.

.Блок EVALUATE TRUE, таким образом:

EVALUATE TRUE
   WHEN ACTION = "START"
      PERFORM START
   WHEN ACTION = "STOP"
      PERFORM STOP
   WHEN ACTION = "PROCESS" AND FILE-NAME = "A"
      PERFORM PROCESS-A-FILE
   WHEN ACTION = "PROCESS" AND FILE-NAME = "B"
      PERFORM PROCESS-B-FILE
   WHEN ACTION = "RESET"
      PERFORM RESET
   WHEN OTHER
      PERFORM INVALID-ACTION-ERROR
END-EVALUATE

Изменение этого EVALUATE на TRUE ALSO TRUE сделает его гораздо менее читабельным, и это действительно не нужно.

0 голосов
/ 02 декабря 2011

Я могу сказать, что облегчает жизнь в определенных ситуациях. Скажем, например, где мы добавим еще одно условие, на основе которого нам может понадобиться PERFORM другой фрагмент кода; в этом случае добавление другого WHEN будет проще, чем корректировка условий на IF. Вот точки при сравнении WHEN с условиями настройки на IF:

  • У нас была бы возможность предоставить столько WHEN(s), сколько мы хотим, исходя из выполнения PARAs.
  • IF условия подвержены ошибкам при работе с OR или AND параметрами
  • Также WHEN дает четкое представление о том, как обстоят дела, когда нам, возможно, придется настроить наши очки при анализе IF (s). [Это может случиться, когда у нас сложные циклы, но как эффективный программист мы должны прогнозировать такие сценарии]
  • И последнее, но не менее важное: переустановить код до прежнего состояния было бы легко с меньшим числом IFs.

Но в вашем текущем случае я не чувствую особой ясности и разницы между EVALUATE и IF. Итак, перейдите на тот, который делает вас счастливым:)

...