Я знаю, что это основной вопрос, но я не мог найти ответ.
Зачем использовать это? если вы напишите функцию или метод, который ее использует, при удалении ее код все равно будет работать идеально, на 100% без него. Например:
С параметрами:
static public int addTwoEach(params int[] args)
{
int sum = 0;
foreach (var item in args)
sum += item + 2;
return sum;
}
Без параметров:
static public int addTwoEach(int[] args)
{
int sum = 0;
foreach (var item in args)
sum += item + 2;
return sum;
}
c#
parameter-passing
params
variadic-functions
variadic
MasterMastic
источник
источник
*
префиксным параметром asterisk ( ), как упомянуто здесь .Ответы:
С помощью
params
вы можете вызвать свой метод так:Без
params
, ты не можешь.Кроме того, вы можете вызвать метод с массивом в качестве параметра в обоих случаях :
То есть
params
позволяет использовать ярлык при вызове метода.Не связанные, вы можете резко сократить свой метод:
источник
System.Linq
пространство имен :)return args.Select(x => x + 2).Sum();
params
вы блокируете себя от добавления дополнительных аргументов метода, не нарушая ваших вызывающих или разрешения методов.Использование
params
позволяет вызывать функцию без аргументов. Безparams
:Сравните с
params
:Обычно вы можете использовать params, когда число аргументов может варьироваться от 0 до бесконечности, и использовать массив, когда число аргументов варьируется от 1 до бесконечности.
источник
new int[0]
, надеюсь это поможет! :)Это позволяет вам добавлять столько параметров базового типа в ваш вызов, сколько вам нужно.
тогда как со второй формой вы должны использовать массив в качестве параметра
источник
Одна опасность с
params
ключевым словом состоит в том, что, если после того, как вызовы метода были закодированы,params
параметром до изменения подписи были совместимы с типом сparams
параметром,эти вызовы будут продолжать компилироваться с одним / несколькими выражениями, ранее предназначенными для требуемых параметров, которые рассматриваются как необязательный
params
параметр. Я просто столкнулся с наихудшим из возможных случаев:params
параметр был типаobject[]
.Это примечательно тем, что разработчики привыкли к тому, что компилятор шлепает их по запястьям с помощью гораздо более распространенного сценария, в котором параметры удаляются из метода со всеми необходимыми параметрами (поскольку ожидаемое количество параметров может измениться).
Для меня это не стоит ярлыка.
(Type)[]
безparams
будет работать с 0 до бесконечности # параметров без необходимости переопределений. В худшем случае вам нужно будет добавить, new (Type) [] {}
в Calls, где это не относится.Кстати, имхо, самая безопасная (и наиболее читаемая практика) заключается в:
передать через именованные параметры (что мы можем теперь сделать даже в C # ~ 2 десятилетия после того, как мы могли бы в VB; P) (потому что:
1.1. это единственный способ, который гарантирует предотвращение непреднамеренных значений, передаваемых в параметры после изменения порядка параметров, типа совместимости и / или количества после кодирования вызовов;
1.2. это уменьшает эти шансы после изменения значения параметра, поскольку вероятное имя нового идентификатора, отражающее новое значение, находится рядом с передаваемым ему значением,
1.3. он избегает необходимости считать запятые и переходить назад и вперед из Call to Signature, чтобы увидеть, какое выражение передается для какого параметра, и
1.3.1. Кстати, одной этой причины должно быть достаточно (с точки зрения избежания частых нарушений принципа DRY, подверженных ошибкам, только для того, чтобы прочитать код, не говоря уже о том, чтобы изменить его, а также изменить его), но эта причина может быть экспоненциально более важной, если есть одна / Передается больше выражений, которые сами содержат запятые, то есть ссылки на многомерный массив или вызовы функций с несколькими параметрами. В этом случае вы даже не могли бы использовать (что, даже если бы вы могли добавить дополнительный шаг для каждого параметра на вызов метода) функцию «Найти все вхождения» в функции выбора в вашем редакторе, чтобы автоматизировать подсчет запятых для вас.
1.4. если вы должны использовать Необязательные параметры (
params
или нет), это позволяет вам искать Звонки, где определенный Необязательный параметр пропущен (и, следовательно, скорее всего, нет или, по крайней мере, имеет возможность не быть значением по умолчанию),(ПРИМЕЧАНИЕ. Причины 1.2. И 1.3. Могут облегчить и уменьшить вероятность ошибок даже при кодировании начальных вызовов, не говоря уже о том, когда вызовы должны быть прочитаны и / или изменены.))
и
сделайте так ОДИН - ПАРАМЕТР - НА - ЛИНИЮ для лучшей читаемости (потому что:
2.1. это менее загромождено, и
2.2. он избегает необходимости прокручивать вправо и назад влево (и это необходимо делать PER - LINE, поскольку большинство смертных не может прочитать левую часть нескольких строк, прокрутить вправо и прочитать правую часть)).
2,3. это согласуется с «передовой практикой», в которую мы уже вошли для операторов присваивания, потому что каждый переданный параметр по сути является оператором присваивания (присваивая значение или ссылку на локальную переменную). Точно так же, как те, кто следит за последней «Лучшей практикой» в стиле кодирования, не будут мечтать о кодировании нескольких операторов присваивания на строку, мы, вероятно, не должны этого делать (и однажды «Лучшая практика» не догонит моего «гения»; P) ) делать это при передаче параметров.
ЗАМЕЧАНИЯ :
Передача переменных, чьи имена отражают параметры, не помогает, когда:
1.1. вы передаете литеральные константы (т. е. простые 0/1, false / true или null, для которых даже в «Best Practices» может не потребоваться использование именованной константы, и их назначение не может быть легко определено из имени метода ),
1.2. метод является значительно более низким уровнем / более общим, чем вызывающий, так что вы не захотите / не сможете назвать свои переменные такими же / похожими на параметры (или наоборот), или
1.3. вы будете повторно заказ / замена параметров в подписи , что может привести в предыдущих вызовах еще компиляции , потому что типы случаются по - прежнему быть совместимы.
Наличие функции автоматического переноса типа VS исключает только ОДНУ (# 2.2) из 8 причин, которые я привел выше. До VS 2015 года это НЕ делало авто-отступ (!?! Действительно, MS?!?), Что увеличивает серьезность причины # 2.1.
В VS должна быть опция, которая генерирует фрагменты вызова метода с именованными параметрами (по одному на строку, конечно, P) и опцией компилятора, которая требует именованных параметров (аналогично концепции Option Explicit в VB, который, между прочим, требовался совсем недавно) в равной степени возмутительно, но в настоящее время требуется "" передовой опыт "). На самом деле "обратно в мойдень ";), в 1991 году, всего за несколько месяцев до моей карьеры, даже до того, как я использовал (или даже видел) язык с именованными параметрами, у меня был анти-овец /" просто потому что ты можешь, не значит, что должен " / не слепо «обрезать концы жаркого» достаточно, чтобы смоделировать его (используя встроенные комментарии), не видя, чтобы кто-то это делал. Не нужно использовать именованные параметры (а также другой синтаксис, сохраняющий «драгоценный») нажатия клавиш исходного кода) является пережитком эпохи перфокарт, когда началось большинство этих синтаксисов. Этому нет оправдания с современным оборудованием и средами IDE, а также с гораздо более сложным программным обеспечением, где читаемость намного, МНОГО , МНОГОболее важный. «Код читается гораздо чаще, чем пишется». Пока вы не дублируете не-автоматически обновляемый код, каждое сохраненное нажатие клавиш, вероятно, будет стоить экспоненциально дороже, если кто-то (даже вы) попытаетесь прочитать его позже.
источник
null
илиnew object[0]
в качестве аргумента.myMethod
какvoid myMethod(int requiredInt, params int[] optionalInts)
. I / кто - то другой код один / несколько вызовов, то естьmyMethod(1)
,myMethod(1, 21)
,myMethod(1, 21, 22)
. Я изменяюсь,myMethod
чтобы бытьvoid myMethod(params int[] optionalInts)
. Все эти вызовы будут по-прежнему компилироваться без ошибок, даже если их 1-е параметры («1») явно не предназначались для передачи в качестве 1-го элементаoptionalInts
параметра.Нет необходимости создавать методы перегрузки, просто используйте один единственный метод с параметрами, как показано ниже
источник
params
или без мы просто передали бы тип коллекции, чтобы покрыть любое количество коллекций.params
также позволяет вызывать метод с одним аргументом.т.е.
Foo(1);
вместоFoo(new int[] { 1 });
. Может быть полезно для сокращения в сценариях, где вам может потребоваться передать одно значение, а не весь массив. Он все еще обрабатывается в методе так же, но дает некоторую конфету для вызова таким образом.источник
Добавление ключевого слова params само по себе показывает, что при вызове этого метода вы можете передать несколько параметров, что невозможно без его использования. Чтобы быть более конкретным:
Когда вы вызовете вышеуказанный метод, вы можете вызвать его любым из следующих способов:
addTwoEach()
addTwoEach(1)
addTwoEach(new int[]{ 1, 2, 3, 4 })
Но когда вы удалите ключевое слово params, только третий способ из приведенных выше будет работать нормально. Для 1-го и 2-го случая вы получите ошибку.
источник
Еще одна важная вещь должна быть выделена. Лучше использовать,
params
потому что это лучше для производительности. Когда вы вызываете метод сparams
аргументом и ничего не передаете ему:вызов:
Затем новые версии .Net Framework делают это (из .Net Framework 4.6):
Этот
Array.Empty
объект может быть повторно использован платформой позже, поэтому нет необходимости делать избыточные выделения. Эти распределения будут происходить, когда вы вызываете этот метод следующим образом:источник
Звучит глупо, но Params не допускает многомерный массив. Принимая во внимание, что вы можете передать многомерный массив в функцию.
источник
Другой пример
источник