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

Question

Я недавно установил модуль из 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;?

Answer 1

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

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

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

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

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

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

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

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

или

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

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

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

обновление

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

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

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

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

use Moose;
use common::sense;

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

Answer 2

Есть один бит, который никто, похоже, не заметил, и это 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 

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

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

Answer 3

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

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

Answer 4

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

Answer 5

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

Answer 6

Не у всех идея здравого смысла одна и та же - в этом отношении она не является чем-то общим.

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

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

Answer 7

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

Answer 8

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

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

Answer 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 строками ...