допустимо ли перерабатывать или повторно использовать переменные? - PullRequest
5 голосов
/ 01 февраля 2012

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

В этом примере $ table_name установлено в другом месте.

class DbObject {
    private $db = NULL;
    protected $table_name;

    public function __construct($dbh, $item) {
        $this->db = $dbh;
        $this->$table_name = $item;
    }

    // counts items in database //
    public function count_all() {
        try {
            $sql = 'SELECT COUNT(*) FROM ' . $this->table_name;

            $stmt = $this->db->query($sql);
            $stmt->setFetchMode(pdo::FETCH_COLUMN, 0);
            $result = $stmt->fetchColumn();
            return $result;
        } catch (PDOException $e) {
            echo $e->getMessage());
        }
}

Чтобы использовать это, я бы использовал это так:

$total_count = new DbObject(new Database(), 'items');
$total_count = $total_count->count_all();

Это приемлемый способ кодирования?Спасибо за вашу помощь.

Ответы [ 6 ]

11 голосов
/ 01 февраля 2012

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

Это плохая практика.Хорошо названная переменная может творить чудеса для облегчения понимания кода.

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

[В недалеком прошлом я сталкивался с ошибками в производственном коде (подождите, я думаю, это был мой!), Гдеповторное использование локальных переменных цикла, таких как i и j, приводит к ошибкам ...]

3 голосов
/ 01 февраля 2012

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

$foo = $_GET['input'];
# use $foo

if ($a == $b) {
    $foo = 1;
} else {
    # $foo = 2; # Commented out for some reason
}
# Value $foo supplied in URL leaks through to here

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

2 голосов
/ 01 февраля 2012

Как насчет того, когда вам нужно вызвать другой метод DbObject?

Я предпочитаю дать имя переменной, что это такое:

$dbo = new DbObject(new Database(), 'items');
$total_count = $dbo->count_all();

//so you call still do things next
$result = $dbo->get_all();
1 голос
/ 01 февраля 2012

Если вам нравится часто использовать общие имена в сценарии (например, $i для подсчета итераций в цикле), у вас не должно возникнуть проблем, если вы привыкли вызывать unset() всякий раз, когда вы закончите с использованием переменная в конкретном случае.

1 голос
/ 01 февраля 2012

Люди, как правило, используют повторно «выбрасываемые» переменные, такие как i и j , но обычно неправильно использовать другие локальные переменные для другой цели. Это приводит к путанице читателя о том, где инициализируется переменная и влияют ли обновления в одной части кода на другую часть кода. Также могут быть негативные последствия для пакета оптимизации компилятора (возможно, предлагается сохранить переменную, когда в этом нет необходимости).

0 голосов
/ 01 февраля 2012

Иногда переменные могут конфликтовать, или вы можете смешать их.Поэтому я бы только использовал $i и $row, если вы не unset() переменную, когда вы закончите.

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