- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
if ( $MonitorMode eq \">=\" )
{
if ( $NbrProcesses < $ProcNumber )
{
$Rule->Status(TRUE);
}
}
elsif ( $MonitorMode eq \"<=\" )
{
if ( $NbrProcesses > $ProcNumber )
{
$Rule->Status(TRUE);
}
}
else
{
if ( $NbrProcesses != $ProcNumber )
{
$Session->Value(\"PROCESSMODE\", \"\" );
$Rule->Status(TRUE);
}
};
Follow us!
нормальный код. просто и понятно. по нему можно учится как из мух слонов не делать. но я догадываюсь что из простого и понятного большой карьеры не сделаешь, почему этот код и говно. тем более, если его каждый индус может понять и - еще хуже - поменять, то карьера закончится еще скорее. быстрее апгрейдим все на энтерпрайз! https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
Да, в кавычках - оно часть конфигурационного файла лежащего в БД
э? ты про что?
$MonitorMode это очевидно состояние, а как во всех нормальных fsm первая проверка, это проверка состояния.
> цикломатическую сложность
каким именно из 73 мне известных определений вы пользуетесь? поройтесь немного, найдете себе определение маккэйба по которому этот код будет просто само совершенство.
У исходного кода она, грубо, 16, а при уходе от внутренних if'ов - уже 6.
Ну и на счет состояния можно с тем же успехом утверждать, что состояние - это $ProcNumber, а $MonitorMode- это модификатор влияющий на способ проверки этого состояния
классическое определение не уточняет что именно является нодом этого графа. и каждая тулза определяет по своему. я эвалюацию делал ~2 года назад - может только и на однострочниках эти тулзы соглашались о метрике. на всем нетривиальном - разброд и шатание.
с другой стороны, ты тогда должен радоватся что тут не switch/case. иначе бы сложность была 123123123123123, плюс/минус 1.
вот такой вариант на порядок читабельнее и способствует пониманию происходящего при беглом просмотре, без спотыкания на ненужной лестнице :)
В этом варианте статус выставляется во всех ветках. В топике если мод >=, но условие на число процессов не выполнено, ничего не произойдёт, т.к. альтернативные ветки не будут просматриваться.
($MonitorMode eq ">=") && ($NbrProcesses < $ProcNumber) - это одно логическое выражение, атомарное относительно if. Если оно ЦЕЛИКОМ не выполняется, то управление передается следующему elsif
> Если оно ЦЕЛИКОМ не выполняется, то управление передается следующему elsif
Вот именно поэтому.
Давай проверим на конкретных значениях. Допустим, выполнены условия:
$MonitorMode = ">="
$NbrProcesses > $ProcNumber
В коде из топика мы войдём в первую ветку (if ( $MonitorMode eq \">=\" )), проверим условие ( $NbrProcesses < $ProcNumber ), сочтём его ложным и на этом успокоимся. Остальные условия проверяться не будут, потому что самый первый if уже сработал.
В твоём коде мы получим false в первой и во второй ветках, в итоге сработает последняя и выставит Status(TRUE).
Видишь, код не эквивалентный.
И ведь хотел другой вариант предложить изначально, но, так как давно с перлом не общался, решил не выделываться :)
AS учитывая, что там в коде сначала по умолчанию FALSE устанавливается
Тогда оно и работать корректно будет и определяем условие явно, что тоже плюс
А вот это годный фикс. В оригинальном коде он бы тоже не помешал. А то сиди и думай, что там в else обрабатывается - "==" или "!=".
ЗЫ ты and/or думаю перепутал. ты хотел &&/||. но вроде у тебя тут это к багу не ведет.
Ты прав, код сильно проще не сделаешь.
оригинальный код подоходит к правилам "явного программирования" (которые никто никогда конкретно не сформулировал). это когда у тебя на одну строчку одно выражение, и нет никаких/минимальные побочные эффекты.
Красной водой поливает восход,
Кленёночек маленький матке
Зелёное вымя сосёт.
Рвётся образ с языка:
Отелившееся небо
Лижет красного телка.
Действительно, монголы же не к нему выехали.
1. Проверяется один режим, а проверка, по-факту, выполняется другая. Для ясности перевернул второе условие.
2. Совершенно не ясно, являются ли эти случаи попарно равнозначными