Почему «!!» считается плохой формой в Perl?

Я бы назвал это "плохой формой", потому что это просто не нужно. Вы не нуждаетесь в логическом преобразовании в Perl. И поэтому в лучшем случае это избыточно, а в худшем случае это запутывание.

Несмотря на то, что в Perl есть несколько действительно хороших трюков, одна из самых больших проблем с языком (по крайней мере, по восприятию) заключается в том, что он скорее склонен к "писать один раз".

В конце концов - зачем вам когда-либо понадобиться "двойное отрицание" скаляра, чтобы получить логическое значение, когда вы можете просто проверить скаляр?

my $state = !! 'some_string';
if ( $state ) { print "It was true\n" };

Или:

if ( 'some_string' ) { print "It was true\n" };

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

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

Относительно альтернатив;

while (my $line = <$F>) {
    # snip
    exists $counts{lines} and $counts{lines} += !! chomp $line;
}

Это... подсчет, как часто вы успешно chomp редактировали строку, я думаю? Таким образом, в основном он просто подсчитывает количество строк на вашем входе.

Для этого я бы подумал "используйте $.". Разве я не пропустил что-то глубокое о вашем коде?

"Что делать, если он не горит?"

Хорошо, хорошо. Как насчет:

 $counts{lines}++ if foo();

Для этого:

sub foo {
    my ($input) = @_;
    my %responses = ( "" => "False", 1 => "True" );
    return $responses{ !! $input };
}

Я бы написал это как:

sub foo {
    my ($input) = @_;
    return $input ? "True" : "False";
}

Для последнего условия - упаковка флагов в байт:

sub flags {
    my @boolean_flags = @_;
    my $flags = 0;
    for ( @boolean_flags ) {
        $flags<<=1;
        $flags++ if $_;
    }
    return $flags;
}

print flags ( 1, 1, 1 );

Или, может быть, если вы делаете что-то вроде этого - беря лист от того, как Fcntl делает это, определяя значения для добавления на основе позиции, так что вы не беспокоясь о проблеме позиционных аргументов:

Вы можете запросить, чтобы константы flock() (LOCK_SH, LOCK_EX, LOCK_NB и LOCK_UN) были предоставлены с помощью тега :flock.

И затем вы можете:

flock ( $fh, LOCK_EX | LOCK_NB );

Они определены поразрядным образом, поэтому они "добавляют" через оператор or, но это означает, что это идемпотентная операция, где установка LOCK_NB дважды не будет.

Например,

 LOCK_UN = 8
 LOCK_NB = 4
 LOCK_EX = 2
 LOCK_SH = 1

Если мы разберем вопрос на менее субъективный:

Я прошу причины, чтобы избежать!

• Perl оценивает "правду" переменных, поэтому на самом деле нет необходимости в фактическом логическом логическом выражении.
• Условные утверждения яснее их эквивалентной булевой алгебры. if ( $somecondition ) { $result++ } понятнее, чем $result += !! $somecondition.
• Это в секретном списке операторов, потому что это неясно. Ваши будущие программисты по обслуживанию могут не оценить это.
• !!1 - 1, !!0 - dualvar('', 0). Хотя это довольно гибко, это может удивить, тем более, что большинство людей даже не знают, что такое dualvar, тем более что ! возвращает один. Если вы используете тернар, то явные значения, которые вы получаете: $value ? 1 : 0

Весь вопрос несколько субъективен, поэтому я хотел бы дать мнение, которое отличается от других ответов, опубликованных до сих пор. Я бы не рассматривал плохую форму двойного отрицания вообще, но я бы постарался избежать ее, если есть более читаемая альтернатива. Что касается ваших примеров:

• Используйте что-то вроде $count++ if $condition.

• Значения истины как хеш-ключи? Это просто зло. По крайней мере, это удивительно для всех, кто должен поддерживать ваш код.

• Здесь использование !! оправдано.

• Здесь я бы использовал тернарный оператор. На самом деле не совсем ясно, как execute ведет себя при передаче двоичного файла.

Другая ситуация, когда полностью использовать !!, - это приведение определенных значений в Boolean, например, в оператор return. Что-то вроде:

# Returns true or false.
sub has_item {
    my $self = shift;
    return !!$self->{blessed_ref};
}

Большинство программистов должны знать идиому !! из статически типизированных языков, где она часто используется в качестве броска для bool. Если это то, что вы хотите сделать, и нет опасности нежелательных побочных эффектов, идите с двойным отрицанием.

Возможно, это не так плохо для кода, который вы видите только.

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

• Он думает, что вы допустили ошибку и удалил один !, недействительный код
• Он думает, что это всего лишь программная гниль, и удаляет обе !! без второй мысли. После рефакторинга какого-то другого кода он внезапно зависает... несоответствие типа?

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

В зависимости от работы, это плохая форма для многих деловых и собеседований, а также...

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

p.s. было бы в хорошей форме спросить интервьюера, почему он считал его "плохим". Удобный совет для интервью, будет послать ему благодарность и спросить его, почему он считает это "плохой формой"