- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
/**
* Returns the number of rows affected by the last query
*
* @return int
*/
public function getAffectedRowCount($result)
{
return mysqli_affected_rows($this->getDatabase());
}-
PHP / Говнокод #16060
+155
SugarCRM. Стоит от $35/месяц на одного пользователя.
Понимаю когда такое встречатеся в стартапах, но когда ты просишь за свой продукт деньги и деньги не малые, то выпускать такое в продакшен... Лично я бы постеснялся.Запостил:
VanSanblch,
27 Мая 2014
Follow us!
А может быть это одна из реализаций абстрактного метода, а в какой-то другой из них этот $result используется? В таком случае неиспользуемая переменная - вполне норм.
Проект вообще "славится" тем что на вывод ошибок нужно отключать не только на продакшене, но и на деве. Иначе всё засирается нотисами, варнингами и стриктами.
Да ну? Если бы это был абстрактный метод, то в одной из его реализаций так делать не стоит (в самом интерфейсе - можно). Нарушение контракта интерфейса/базового класса и все такое: потом получится, что никто не передает туда $result, а одной из СУБД он нужен.
Либо выпилить параметр из интерфейса вообще. Либо он должен быть везде. Либо все реализации должны нормально работать, если им не передали $result'а.
В общем как-то так:
1) В интерфейсе написано foo($result). Реализации имеют полное право не юзать его. Вызывающие обязаны передавать, т.к. какой-то из реализаций он может понадобиться.
2) В интерфейсе написано foo($result=''). Реализации обязаны нормально работать с пустым $result'ом, т.к. его могут не передать. Вызывающий имеет полное право его не передавать.
Все остальные варианты, к примеру, foo($result) в интерфейсе и foo($result='') в реализации - сраное говно, с которым ты рано или поздно прострелишь себе ногу.
Но заставлять пользователя класса передавать параметр "что бы было" никуда не годится.
1) Программисты написали тонны кода, которые foo() юзали не передавая параметр (влом же, да и интерфейс позволяет).
2) Появилась реализация, которой $result все-таки нужен, и он без нее никак жить не может (ну СУБД, например, такая попалась, что без result'а не может вернуть статистику).
3) Кто-то попытался поюзать код из 1 с реализацией из 2 - кровь-кишки-распидорасило.
Что делать будем в такой ситуации? :)
P.S.Само собой, что getAffectedRowCount() - функция чисто информационная, и даже если она вернет 0 - всем похуй. Так что пример рассматриваем на более важной функции, без которой ничего работать не будет.
if (!$result instaceof ResultClass)
throw new Exception('Дайте $result суки!!!1');
Отличное решение! Теперь юзеры твоего продукта матерятся, что большая часть модулей (купленных ими у сторонних разрабов) не работает с новой базой. Что делаем дальше?
WHAT!? Не реализации же, а модули, которые юзали твой интерфейс с foo($result). Они забивали на передачу аргумента, т.к. твоя дока сказала им, что это не обязательно. Они доверяли твоему интерфейсу, пообещавшему им, что он не будет падать, если $result не передать... А теперь на одной из новых СУБД все эти модули тупо не работают, падая с ошибкой... И твое решение - отказаться от этой СУБД, и тупо ее не прикручивать...
А все из-за того, что автор интерфейса решил сэкономить вызывающим десяток символов...
В общем и целом: если ты видишь в интерфейсе ненужные аргументы - это может оказаться не говном, а заделом на будущее. Да и вдруг автор уже знает о базе, где ему этот $result пригодится, просто до ее поддержки руки еще не дошли?
P.S. И именно поэтому разработка качественных интерфейсов - это самая сложная и ответственная задача для разраба.
Ты думаешь почему всяческие менеджеры так любят говнокодеров?
Удаление файлов с вероятностью 1.0/RAND_MAX... Беспощадно, но очень маловероятно.
Преимущество