Do not use underscore as variable name.

[eugene-kartsev]

I'm not sure about the following line:

DO NOT use underscore as variable name. This is incorrect:
task.ContinueWith((_) => _activeTasks.Release());

What would you like to see here? I mean if method accepts Action<Something> and you want to use it as Action (void)? In many languages single underscore means - missing or unused parameter.

[akoshelev]

Agree. IMHO this is the best way to show that you're not using this variable in method body

[maxbrodin]

@eugene-kartsev @akoshelev Do you really need to show that you don't use this variable? Who can use this information and why?

In my opionion this will encourage people to leave this variable name as is when the code below starts using the paramter. For instance you have the code like this

new Timer(_ => UpdateContent().Wait(), null, null, null)

And person who supports your code (it could be you as well) makes change to fix some bug and decide to use the variable, so we end up with code like this:

new Timer(_ => UpdateContent().Wait(), null, _.interval, _.interval);

You can see a lot of such code in the project

var minX = regionsByPage.Min(_ => _.Rect.X);

publisher.Data.Cids = publisher.Data.Cids.Union(Enumerable.Repeat(cid, 1)).OrderBy(_ => _).ToArray();

var notConfirmedIssues = helper.Issues.Values.Where(_ => !_.Confirmed).ToArray();

Also it could be confusing our private field name _fieldName and parameter variable name _. I just don't expect anything over than private fields to have underscode in the name.

My point is let's be consistent and use item or x or any other one letter.
Does it makes sense?

[akoshelev]

From my point of view this syntax shortens the method definition (No need to use meaningful names for variables aren't used in body) and does the most important part of code conventions' job - improves code readability. Once I see variable _ then I immediately understand that this parameter is ignored. If you need to use this parameter - rename and give a semantic name to it.

IMHO this is a well-known pattern and it's using in c# code as well as in other languages. I think it came from functional languages, in particularly F# using this syntax in pattern matching (wildcard)
https://msdn.microsoft.com/en-us/library/dd547125.aspx
and Ramda using it to define a gap in function's parameter array.
http://ramdajs.com/0.18.0/docs/#__

So meaning is the same across languages so, I think, we can safely use the same principles in C#.

[eugene-kartsev]

If we are choosing if we want to see an "x" or "_":

new Timer(x => UpdateContent())

new Timer(_ => UpdateContent())

I would rather see underscore parameter. Because it is used in other languages (as Alex mentioned) like F# or Golang.
And BTW, even if we need to change the inner lambda function - "x" will mean nothing, just like the underscore will:

new Timer(x => UpdateContent(x.Name))

new Timer(_ => UpdateContent(_.Name))

[maxbrodin]

@eugene-kartsev It's all about consistency in variable naming, we will always have parameters as camelCase, and in this particular case it would be different.

new Timer(_ => UpdateContent(_.Name))

also this doesn't look like object property for me 😉

[eugene-kartsev]

Max, my point was if you wanted to change the definition/implementation of the lambda - you would need to change a "missing" parameter as well (whether it is a "x" or an underscore). Nobody wants to leave "_.Name" as a valid parameter usage. I just see no reason of using fake/invalid parameter names for those which are not in use.