Какую идиому (если таковая имеется) вы предпочитаете называть параметром "this" для методов расширения в C # и почему?

Question

Первый параметр метода расширения C # - это экземпляр, в котором был вызван метод расширения. Я принял идиому, не видя этого в другом месте, называть эту переменную «я». Я бы не удивился, если бы другие тоже этим пользовались. Вот пример:

public static void Print(this string self)
{
   if(self != null) Console.WriteLine(self);
}

Однако я начинаю видеть, как другие называют этот параметр "@this" следующим образом:

public static void Print(this string @this)
{
   if(@this != null) Console.WriteLine(@this);
}

И в качестве третьего варианта, некоторые вообще не предпочитают идиомы, говоря, что "self" и "@this" не дают никакой информации. Я думаю, что мы все согласны с тем, что иногда есть четкое, осмысленное имя параметра, специфичное для его назначения, которое лучше, чем "self" или "@this" Некоторые идут дальше и говорят, что вы можете всегда придумать более ценное имя. Так что это еще одна правильная точка зрения.

Какие еще идиомы вы видели? Какой стиль вы предпочитаете и почему?

Answer 1

Я называю это вполне нормально, в зависимости от использования. Поэтому «источник» для исходной последовательности оператора LINQ или «аргумент» / «параметр» для расширения, выполняющего проверку параметра / аргумента и т. Д.

Я не думаю, что это должно быть особенно связано с "этим" или "собой" - это не дает никакой дополнительной информации о значении параметра. Конечно, это самая важная вещь.

РЕДАКТИРОВАТЬ: Даже в случае, когда не так много очевидного значения, я бы предпочел некоторые значения нет Какая информация предоставляется "я" или "@this"? Просто, что это первый параметр в методе расширения - и эта информация уже очевидна тем фактом, что параметр украшен this. В примере, где задан параметр theStringToPrint / self, я бы использовал вместо него outputText - он передает все, что вам нужно знать о параметре IMO.

Answer 2

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

Самый простой способ посмотреть на это - проверка аргументов. Рассмотрим случай, когда null передается в ваш метод. Вы должны делать проверку аргументов и генерировать ArgumentNullException. Если он реализован правильно, вам нужно будет указать «this» в качестве имени аргумента.

public static void Print(this string @this) {
  if ( null == @this ) {
    throw new ArgumentNullException("this");
  }
  ...
}

Теперь кто-то кодирует вашу библиотеку и внезапно получает диалоговое окно исключения, которое говорит: «это ноль». Они будут в замешательстве:)

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

Answer 3

Я видел obj и val. Мне это не нравится. Мы должны стараться избегать использования ключевых слов. Я никогда не видел себя, но мне это нравится.

Answer 4

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

Answer 5

Я называю это «целью», так как метод расширения будет работать с этим параметром.

Answer 6

Вы могли бы сделать что-то вроде этого ...

public static void Print(this string extended)
{
   if(extended != null) Console.WriteLine(extended);
}