Касательно злоупотребления: стоящий чистки?
Вы можете использовать эти предложения для загрузки любой составной части
$file = $request->file;
$filename = time() . '.' . $file->getClientOriginalExtension();
$file->move('your-path', $filename);
, и если вам нужно загрузить несколько аудио или изображений, убедитесь, что ваш ключ на почтальоне написан так
images[]
or
audios[]
6 ответов
Я бы сказал, что самая большая опасность в том случае, если параметр был установлен на ноль внутри функции для по какой-то причине:
public void MakeNull(ref Customer person)
{
// random code
person = null;
return;
}
Теперь, вы не просто другой человек, вы полностью стерты из существования!
Пока тот, кто разрабатывает это приложение, понимает, что:
по умолчанию ссылки на объекты передаются по значению.
и:
С ключевым словом
refссылки на объекты передаются по ссылке.
Если код работает, как ожидается, сейчас, и ваши разработчики понимают Разница в том, что, вероятно, не стоит того, чтобы их всех убрать.
Можете ли вы понять, почему создатель кода решил, что ему нужно иметь параметр в качестве ссылки? Было ли это потому, что они обновили его, а затем удалили функциональность, или просто потому, что в то время они не понимали c #?
Если вы считаете, что очистка того стоит, то продолжайте - особенно если у вас есть время сейчас. Возможно, вы не сможете исправить это должным образом, когда возникнет реальная проблема, так как это, скорее всего, будет срочное исправление ошибки, и у вас не будет времени, чтобы сделать правильную работу.
Я просто добавлю худшее использование ключевого слова ref, которое я когда-либо видел, метод выглядел примерно так :
public bool DoAction(ref Exception exception) {...}
Да, вам нужно было объявить и передать ссылку на исключение, чтобы вызвать метод, а затем проверить возвращаемое значение метода, чтобы увидеть, было ли исключение обнаружено и возвращено через исключение ref.
Для меня это пахнет разработчиком C ++, делающим необоснованные предположения.
Я бы с осторожностью относился к массовым изменениям того, что работает. (Я предполагаю, что это работает, потому что вы не комментируете, что это сломано, просто опасно).
Последнее, что вы хотите сделать, - это сломать что-то неуловимое и потратить неделю на отслеживание проблемы. .
Я предлагаю вам убирать по ходу дела - по одному методу за раз.
- Найдите метод, который использует ref, если вы уверены, что он не требуется.
- Измените подпись метода и исправьте вызовы.
- Test.
- Repeat.
Хотя конкретные проблемы, которые у вас есть, могут быть более серьезными, чем в большинстве случаев, ваша ситуация довольно распространена - наличие большой базы кода, которая не соответствует нашему нынешнему пониманию " правильный путь "делать вещи.
Оптовые «апгрейды» часто сталкиваются с трудностями. Рефакторинг по ходу дела - доведение вещей до спецификаций, когда вы над ними работаете - намного безопаснее.
Здесь есть прецедент в строительной отрасли. Например, к электропроводке в более старых (скажем, 19-го века) зданиях не нужно прикасаться, если нет проблем. Когда возникает проблема , тем не менее, новая работа должна быть завершена в соответствии с современными стандартами.
Это довольно часто в C # модифицировать значения аргументов в методах, поскольку они обычно являются значениями, а не ссылками. Это относится как к ссылочным, так и к типам значений; установка ссылки на ноль, например, изменит исходную ссылку. Это может привести к очень странным и болезненным ошибкам, когда другие разработчики работают «как обычно». Создание рекурсивных методов с аргументами ref не требуется.
Кроме того, у вас есть ограничения на то, что вы можете передать по ссылке. Например, вы не можете передавать константные значения, поля только для чтения, свойства и т. Д., Поэтому при вызове методов с аргументами ref требуется много вспомогательных переменных.
И последнее, но не менее важное, если, вероятно, не так хорошо,
I would try to fix it. Just perform a solution wide string replacement with regex and check the unit tests after that. I am aware that this might break the code. But how often do you use ref? Almost never, right? And given that the developer did not know how it works, I consider the chance that it is used somewhere (the way it should) even smaller. And if the code break - well, rollback ...