views:

292

answers:

6

The first parameter to a C# extension method is the instance that the extension method was called on. I have adopted an idiom, without seeing it elsewhere, of calling that variable "self". I would not be surprised at all if others are using that as well. Here's an example:

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

However, I'm starting to see others name that parameter "@this", as follows:

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

And as a 3rd option, some prefer no idiom at all, saying that "self" and "@this" don't give any information. I think we all agree that sometimes there is a clear, meaningful name for the parameter, specific to its purpose, which is better than "self" or "@this". Some go further and say you can always come up with a more valuable name. So this is another valid point of view.

What other idioms have you seen? What idiom do you prefer, and why?

+2  A: 

I have seen obj and val used. I do not like @this. We should try to avoid using keywords. I have never seen self but I like it.

JoshBerke
I tend to agree abotu shying away from keywords.
Charlie Flowers
@this isn't a keyword.
Daniel Earwicker
You use @ to escape keywords this is a keyword.
JoshBerke
+1  A: 

You could do something like this...

public static void Print(this string extended)
{
   if(extended != null) Console.WriteLine(extended);
}
J.13.L
No you couldn't :) Did you mean to use "@this" consistently, or "extended" consistently?
Jon Skeet
He's just pointing out that you have a typo. In one place you still use "@this" and in the other, you use "extended".
Charlie Flowers
Thanks for the catch...
J.13.L
+14  A: 

I name it fairly normally, based on the use. So "source" for the source sequence of a LINQ operator, or "argument"/"parameter" for an extension doing parameter/argument checking, etc.

I don't think it has to be particularly related to "this" or "self" - that doesn't give any extra information about the meaning of the parameter. Surely that's the most important thing.

EDIT: Even in the case where there's not a lot of obvious meaning, I'd prefer some meaning to none. What information is conferred by "self" or "@this"? Merely that it's the first parameter in an extension method - and that information is already obvious by the fact that the parameter is decorated with this. In the example case where theStringToPrint/self option is given, I'd use outputText instead - it conveys everything you need to know about the parameter, IMO.

Jon Skeet
In many cases, I agree with you. But often an extension method is so generic that there's no better name than something like "theStringToPrint". I will edit my post to make a distinction between these 2 cases.
Charlie Flowers
I'll edit my answer to cover that too then :)
Jon Skeet
Cool. I cannot say I am convinced, but you certainly have a reasonable point of view. I know I have written extension methods both ways. When there is a meaningful name I use it. But there are many cases where it feels the best info I can give is that this is the "self-like" parameter.
Charlie Flowers
What would you call that parameter for a non-extension static method?
Jon Skeet
Just to clarify - I'm definitely playing devil's advocate to some extent. We've all written methods where the parameter name is basically the type name: "Customer customer" etc. That doesn't add much value either. I think I prefer it to "self" or "this" though, as it still describes the parameter.
Jon Skeet
I agree with Jon. Also keep in mind that an extension method can still be called the usual way, and then calling the "this" parameter 'self' or such may be confusing.
jalf
There's something subtle here that is important not to overlook. It is true that all extension methods are implemented as static methods and can be called as such. However, the extension method is a new concept (to C#), and conceptually it does not exactly overlap with the concept of static ...
Charlie Flowers
... methods. There will be cases where an extension method makes sense where a static method would not make sense, and vice versa. From one angle, the fact that they're static methods could be considered a mere "implementation detail". We say "it's just sugar", but sugar has a way of becoming ...
Charlie Flowers
... more than just sugar. It leads us down different paths that we would not have chosen before. And then the "forces" at work are different, and different approaches make sense ... which leads to different idioms and other differences.
Charlie Flowers
I'm not sure that I agree, Charlie. Certainly there are extension methods which are much, much more useful because they're extension methods - but can you give an example of where a static method *wouldn't make sense*? (Vice versa I quite agree with.)
Jon Skeet
+1  A: 

I call it 'target', since the extension method will operate on that parameter.

Frederik Gheysels
+2  A: 

I believe @this should be avoided as it makes use of the most useless language-specific feature ever seen (@). In fact, anything that can cause confusion or decrease readability such as keywords appearing where they are not keywords should be avoided. self reminds me of python but could be good for a consistent naming convention as it's clear that it's referring to the instance in use while not requiring some nasty syntactic trickery.

emaster70
+2  A: 

I name the variable exactly how I would name it if it were a plain old static method. The reason being that it can still be called as a static method and you must consider that use case in your code.

The easiest way to look at this is argument validation. Consider the case where null is passed into your method. You should be doing argument checking and throwing an ArgumentNullException. If it's implemented properly you'll need to put "this" as the argument name like so.

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

Now someone is coding against your library and suddenly gets an exception dialog which says "this is null". They will be most confused :)

This is a bit of a contrived example, but in general I treat extension methods no different that a plain old static method. I find it makes them easier to reason about.

JaredPar