php: есть ли веские причины указывать все ключи / индексы массива? - PullRequest
2 голосов
/ 13 апреля 2011

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

Например:

$ row_rsCatalogsItems [Имя]

вместо

$ row_rsCatalogsItems [ 'Имя']

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

Предложения

Ответы [ 3 ]

9 голосов
/ 13 апреля 2011

Существует более одной веской причины.

Выполните

error_reporting(E_ALL);

в начале вашего сценария, и вы увидите все причины сразу.

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

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

Обновление: Я не рассматривал проблему практического решенияв соответствии с существующей ситуацией, вот что я бы сделал на вашем месте:

  1. Найдите ответственного за это лицо и убедитесь, что он никогда, никогда не сделает это снова любыми необходимыми способами.
  2. Запустите проблемный скрипт и получите все уведомления о неопределенных константах из файла журнала.
  3. Используя поиск и замену регулярных выражений из вашего редактора, попробуйте заменить \[(a-zA-Z_-)\] на ['$1'] (или что-то подобное).Если количество замен равно количеству уведомлений в лог-файле, вы золотые.В противном случае, попробуйте разделить и завоевать, пока не увидите, где происходит сбой регулярного выражения.
  4. Повторите, как требуется для всех других сценариев.
2 голосов
/ 13 апреля 2011

Технически неправильно делать это таким образом.Вы, вероятно, должны использовать одинарные кавычки.Он будет использовать меньше циклов ЦП и памяти для запуска кода, если вы исправите их.Вы заметите разницу, даже если в одном файле зафиксировано 1000 из них?Возможно нет.

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

1 голос
/ 13 апреля 2011

Я бы добавил цитаты. Если ничего другого, чтобы убедиться, что:

  1. Читаемость кода не уменьшается (что происходит, если кто-то думает, что вы используете некоторую константу, а не строковое значение)
  2. Дополнительные циклы не тратятся на каждую оценку

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

$input = '$row_rsCatalogsItems[Name]';
$str = preg_replace('/(\$[a-zA-Z_]+\[)([a-zA-Z]+)(\])/', '${1}\'${2}\'${3}', $input);
echo $str;

(Возможно, вы захотите пройтись по изменениям, используя это выражение, просто чтобы убедиться, что вы меняете правильные вещи;))

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...