Как я могу сортировать одну по возрастанию, другую по убыванию без использования $ b (сравнение) $ a в Perl?

Question

В Perl, я могу сделать:

my @unit_indices = sort { 
    $units{$b}[0] <=> $units{$a}[0] 
     or 
    $a cmp $b 
} keys %units; 

, который сортирует по одному полю (массив элементов), сходящего и другой (хэш-ключ) восходящей, но вызывает perlcritic жаловаться:

упаси $ B перед $ a в блоках сортировки по строке X, столбец Y. См. стр. 152 PBP. (Серьезность: 1)

Perl Best Practices рекомендует использовать вместо reverse.

Но операция была бы гораздо более понятной, если Вы писали:
@sorted_results = обратный порядок сортировки @unsorted_results;

Однако я не нашел способ иметь подсерии, которые работают в противоположных направлениях.

Очевидно, я могу сказать perlcritic, чтобы проигнорировать это, но я хотел бы знать, как выполнить то, что мне нужно, и сделать perlcritic счастливым.

Answer 1

Я согласен с комментарием tchrist, но принимая ваш вопрос по номинальной стоимости:

1) использовать ## no critic

my @unit_indices = sort { ## no critic (ReverseSortBlock) 
    $units{$b}[0] <=> $units{$a}[0] 
     or 
    $a cmp $b 
} keys %units; 

2) Используйте .perlcriticrc файл

[-BuiltinFunctions::ProhibitReverseSortBlock] 

3) Изменение смысл вашего сравнения

my @unit_indices = sort { 
    -($units{$a}[0] <=> $units{$b}[0]) 
     or 
    $a cmp $b 
} keys %units; 

my @unit_indices = sort { 
    -$units{$a}[0] <=> -$units{$b}[0]) 
     or 
    $a cmp $b 
} keys %units; 

Answer 2

Perl :: Критик порой больше будет относиться к тому, чтобы быть точным воспроизведением PBP, чем представлять хорошую политику, а некоторые из Perl Best Practices не выдерживали хорошо. Например, по-прежнему устарело Miscellanea::RequireRcsKeywords.

Perl :: Политика критика не должна рассматриваться как канон. У них нет способности делать субъективный анализ, чтобы решить, действительно ли «исправление» будет увеличивать сложность, особенно когда уровень серьезности падает, а преимущества становятся все более узкими и уже. BuiltinFunctions::ProhibitReverseSortBlock - это «косметическая» политика уровня и попадает прямо в эту категорию.

В то время как кто-то может пропустить $b cmp $a и прочитать его в обратном направлении, это не сложно понять, если посмотреть на него прямо, не стоит накладных расходов на вспять весь массив после этого и, безусловно, не стоит искажать ваш блок сортировки, чтобы соответствовать ограничениям анализа политики. Их решение не изменять поведение по умолчанию, чтобы ограничить политику простыми блоками сортировки, неверно. Ваш блок сортировки явно выходит за рамки письменной политики и запускается только потому, что реализация политики Perl :: Critic ограничена.

Просто потому, что Perl :: Critic имеет политику по умолчанию, не означает, что они представляют собой хорошую практику или что они должны слепо следовать. Не стесняйтесь настраивать его на вкус вашего проекта, для этого нужен Perl :: Critic на самых придирчивых уровнях.Для того, чтобы не допустить, чтобы perlcritic от глупости стал привычным, я бы рекомендовал предпочесть решения политики в масштабе всего проекта в .perlcritic, чтобы индивидуально их отстроить.

Помните, что дело не в том, чтобы быть довольным счастливым, дело в том, чтобы написать лучший код.

Answer 3

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

Обязательно используйте reverse sort { $a <=> $b } более sort { $b <=> $a }, но это невозможно сделать здесь.

Не делайте код хуже, чтобы отключить ложное предупреждение. Иногда это предупреждение является неправильным, и в этом случае вам следует обратиться к предупреждению.