Какую идиому (если таковые имеются) Вы предпочитаете для именования “этого” параметра к дополнительным методам в C#, и почему?
Допустим, у вас есть функция с именем my_func(a, b), которая принимает два скаляра a и b в качестве аргумента и возвращает другой скаляр.
Скажем, ваши два двумерных массива это arr_a и arr_b.
Затем выражение:
my_func(arr_a[:size,:size], arr_b[:size,:size])
будет возвращать массив пустых фигур (size,size), так что каждый элемент в этом массиве результатов получается путем взятия соответствующих скаляров из arr_a и arr_b и передача их в my_func(a,b)
Это работает, если то, что вы делаете внутри my_func() , соответствует определенным правилам .
Например, my_func() может быть:
def my_func(a,b):
return np.lcm(a,b)
или может быть:
def my_func(a,b):
return a%b
6 ответов
Я видел obj и используемый val. Мне не нравится @this. Мы должны постараться не использовать ключевые слова. Я никогда не видел сам, но мне нравится он.
Я называю переменную точно, как я назвал бы ее, если бы это был простой статический метод. Так как причина - это, это можно все еще назвать как статический метод, и необходимо полагать что вариант использования в коде.
Самым легким способом посмотреть на это является проверка аргумента. Рассмотрите случай, куда пустой указатель передается в Ваш метод. Необходимо делать проверку аргументов и бросать ArgumentNullException. Если это будет реализовано правильно, то необходимо будет поместить "это" как имя аргумента как так.
public static void Print(this string @this) {
if ( null == @this ) {
throw new ArgumentNullException("this");
}
...
}
Теперь кто-то кодирует против Вашей библиотеки и внезапно получает диалоговое окно исключения, которое говорит, что "это является пустым". Они будут самыми смущенными :)
Это - определенный изобретенный пример, но в целом я рассматриваю дополнительные методы, не отличающиеся что простой статический метод. Я нахожу, что это делает их легче рассуждать о.
Я называю его справедливо обычно, на основе использования. Так "источник" для исходной последовательности оператора LINQ или "аргумент" / "параметр" для параметра/проверки аргументов выполнения расширения, и т.д.
Я не думаю, что это должно быть особенно связано с "этим" или "сам" - который не дает дополнительной информации о значении параметра. Конечно, это - самая важная вещь.
Править: Даже в случае, где нет большого очевидного значения, я предпочел бы некоторое значение ни одному. Какая информация присуждена "сам" или "@this"? Просто то, что это - первый параметр в дополнительном методе - и та информация уже очевидна тем, что параметр украшен this. В случае в качестве примера, где theStringToPrint/self опция дана, я использовал бы outputText вместо этого - это передает все, что необходимо знать о параметре, IMO.
Я называю это 'целью', так как дополнительный метод будет воздействовать на тот параметр.
Я полагаю, что @this нужно избежать, поскольку он использует самую бесполезную определенную для языка функцию, когда-либо замеченную. На самом деле чего-либо, что может вызвать беспорядок или уменьшить удобочитаемость, такую как появление ключевых слов, где они не ключевые слова, нужно избежать. сам напоминает мне о Python, но мог быть хорош для последовательного соглашения о присвоении имен, поскольку ясно, что это относится к экземпляру, используемому, не требуя некоторого противного синтаксического обмана.
Вы могли сделать что-то вроде этого...
public static void Print(this string extended)
{
if(extended != null) Console.WriteLine(extended);
}