Должен ли я использовать общий:: смысл или просто придерживаться `use strict` и` use warnings`?

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

use common::sense;

# supposed to be the same, with much lower memory usage, as:
#
# use strict qw(vars subs);
# use feature qw(say state switch);
# no warnings;
# use warnings qw(FATAL closed threads internal debugging pack substr malloc
#                 unopened portable prototype inplace io pipe unpack regexp
#                 deprecated exiting glob digit printf utf8 layer
#                 reserved parenthesis taint closure semicolon);
# no warnings qw(exec newline);

Сохранить для undef предупреждений, иногда являющихся суматохой, я обычно обнаружил, что стандартные предупреждения являются хорошими. Стоит ли переключиться на common::sense вместо обычного use strict; use warnings;?

ОТВЕТЫ

Ответ 1

В то время как мне нравится идея сокращения кода котельной плиты, я глубоко подозрительно отношусь к инструментам вроде Modern:: Perl и common:: sense.

Проблема с такими модулями заключается в том, что они группируют группу поведений и скрывают имена glib с изменяемыми значениями.

Например, Modern::Perl сегодня состоит из включения некоторых функций perl 5.10 и использования строгих и предупреждений. Но что происходит, когда Perl 5.12 или 5.14 или 5.24 выходят с отличными новыми позитивами, и сообщество обнаруживает, что нам нужно использовать прагму frobnitz повсюду? Будет ли Modern:: Perl обеспечивать последовательный набор поведений или он останется "современным". Если MP поддерживает время, он нарушит существующие системы, которые не будут блокировать шаг с требованиями своего компилятора. Он добавляет дополнительное тестирование совместимости для обновления. По крайней мере, моя реакция на депутата. Я буду первым, кто признает, что хроматический примерно в 10 раз умнее меня и лучший программист, но я все еще не согласен с его решением по этому вопросу.

common::sense также имеет проблему с именем. В чью идею здравого смысла? Будет ли это изменяться с течением времени?

Мое предпочтение было бы для модуля, который упростит мне создание моего собственного набора стандартных модулей и даже создание групп связанных модулей/прагм для конкретных задач (например, манипулирование датами, взаимодействие с базами данных, синтаксический анализ html и т.д.).

Мне нравится идея Toolkit, но она отсасывает по нескольким причинам: использует фильтры источников, а макросистема слишком сложна и хрупкой. Я очень уважаю Дамиана Конвей, и он производит яркий код, но иногда он слишком далеко (по крайней мере, для использования в производстве, экспериментирование - это хорошо).

Я не потерял достаточно времени, набрав use strict; use warnings;, чтобы почувствовать необходимость создания моего собственного стандартного модуля импорта. Если бы я почувствовал сильную потребность в автоматической загрузке набора модулей/прагм, то было бы идеально похоже на Инструментарий, который позволяет создавать стандартные группы функций:

use My::Tools qw( standard datetime SQLite );

или

use My::Tools;
use My::Tools::DateTime;
use My::Tools::SQLite;

Инструментарий очень близок к моему идеалу. Его фатальные дефекты - облом.

Что касается выбора прагмы, то это вопрос вкуса. Я бы предпочел использовать случайные no strict 'foo' или no warnings 'bar' в блоке, где мне нужна возможность сделать что-то, что ему требуется, чем отключить проверки всего моего файла. Кроме того, IMO, потребление памяти - это красная селедка. YMMV.

Обновление

Кажется, что существует много (сколько?) разных модулей этого типа, плавающих вокруг CPAN.

  • latest, который больше не является последним. Демонстрирует часть проблемы с именами.
  • Кроме того, uni::perl, который добавляет разрешающую юникодную часть микса.
  • ToolSet предлагает подмножество возможностей Toolkit, но без фильтров источников.
  • Здесь я включу Moose, так как он автоматически добавляет strict и warnings в вызывающий пакет.
  • И, наконец, Acme::Very::Modern::Perl

Распространение этих модулей и возможность перекрытия требований добавляет еще одну проблему.

Что произойдет, если вы напишете код типа:

use Moose;
use common::sense;

Какие прагмы включены с какими параметрами?

Ответ 2

Я бы сказал, придерживайтесь warnings и strict по двум основным причинам.

  • Если другие люди будут использовать или работать с вашим кодом, они (почти наверняка) используются для warnings и strict и их правил. Они представляют собой норму сообщества, с которой вы и другие люди, с которыми вы работаете, могут рассчитывать.
  • Даже если тот или иной конкретный фрагмент кода подходит именно вам, вы, вероятно, не хотите беспокоиться о том, чтобы вспомнить "Является ли это проектом, в котором я придерживаюсь warnings и strict, или тем, где я обращаюсь к common::sense?" Движение вперед и назад между двумя режимами просто смутит вас.

Ответ 3

Есть один бит, который больше никто не подобрал, и что FATAL в списке warnings.

Итак, начиная с 2.0, use common::sense более сродни:

use strict; 
use warnings FATAL => 'all'; # but with the specific list of fatals instead of 'all' that is

Это несколько важная и часто упускаемая особенность предупреждений, которые ограничивают строгость в целом выше. Вместо undef string интерполяции или бесконечной рекурсии, просто предупреждающей вас, а затем продолжающегося несмотря на проблему, она фактически останавливается.

Мне это полезно, потому что во многих случаях интерполяция undef string приводит к еще более опасным ошибкам, которые могут незаметно оставаться незаметными, а сбой и подкачка - это хорошо.

Ответ 4

У меня, очевидно, нет здравого смысла, потому что я больше собираюсь Modern::Perl; -)

Ответ 5

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

Ответ 6

Не все идеи здравого смысла одинаковы - в этом отношении это ничего, кроме общего.

Пойдите с тем, что вы знаете. Если вы получаете предупреждения undef, скорее всего, ваша программа или ее ввод неверны.

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

Ответ 7

У меня никогда не было предупреждения, что в моем коде не было ничего хитрого/просто неправильно. Для меня всегда что-то технически разрешено, что я почти не хочу делать. Я думаю, что полный набор предупреждений неоценим. Если на данный момент вы находите use strict + use warnings, я не понимаю, почему вы хотите перейти на использование нестандартного модуля, который затем является зависимостью для каждого фрагмента кода, который вы пишете здесь...

Ответ 8

Когда дело доходит до предупреждений, я поддерживаю использование любого модуля или встроенной языковой функции, которая дает вам уровень предупреждений, который поможет вам сделать ваш код надежным и надежным, каким он может быть. Предупреждающее предупреждение никому не помогает.

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

Ответ 9

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

Некоторые другие модули изменили API, поэтому ломают вещи, и никто не заботится о них. Например. Moose имеет по крайней мере две вещи, которые устарели сейчас и, вероятно, будут запрещены в некоторых будущих выпусках.

Еще один пример: много лет назад было разрешено писать

for $i qw(some words)

теперь он устарел. И многие другие... И это синтаксис языка CORE.

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

  • если вы пишете программы себе, используйте любой модуль, который вы хотите;)
  • Если вы пишете программу кому-то, где кто-то другой собирается ее использовать, используйте минимальные нестандартные "прагма-подобные" модули (common:: sense, modern:: perl, uni:: perl и т.д.)
  • в вопросах stackoverflow вы можете безопасно использовать common::sense или Modern::Perl и т.д. - большинство пользователей, которые ответят, ваши вопросы, узнают их. Все понимают, чем проще написать use 5.010; для включения strict, warnings and fearures с 10 символами, как с 3 строками...