Resolved Question about constructor

[LudoFromHere]

I'm a noob and I'm wondering, what is the difference between :

public Vehicle(string name, string color, int quantity)
{
    this.name = name;
    this.color = color;
    this.quantity = quantity;
}

And :

public Vehicle(string name, string color, int quantity)
{
    name = name;
    color = color;
    quantity = quantity;
}

Thanks in advance.

 

[JohnH]

this keyword - C# Reference

this keyword (C# Reference)

learn.microsoft.com

The this keyword refers to the current instance of the class

For second snippet VS will warn you about this:

Warning CS1717 Assignment made to same variable; did you mean to assign something else?

 

[LudoFromHere]

Thanks for your answer. Actually, I realise that my question wasn't properly formulated. I should have written:

public Vehicle(string name, string color, int quantity)
{
    this.name = name;
    this.color = color;
    this.quantity = quantity;
}

Versus :

public Vehicle(string aName, string aColor, int aQuantity)
{
    name = aName;
    color = aColor;
    quantity = aQuantity;
}

In other word, what is the benefice of using the keyword "this", instead of the second solution. I can see both in the tutorials.

 

[Skydiver]

Welcome to the forum. In the future, please put your code in code tags. Easiest way to do that is to use the button on the toolbar that looks like </>.

Using this lets you deal with cases when you don't have as much freedom to modify the parameter names. Recall that your parameter names will show up in any autogenerated documentation, you're primary focus should be to provide easy to read documentation for your users of your code. The focus should not be simplify your life as a developer.

Also back in the early days of .NET, the naming conventions recommended by Microsoft was for parameters, local variables, and class fields to all be Camel Cased. Additionally, the naming convention specifically said not to use any prefixes or Hungarian notation. So if you were following the naming conventions, you could not use m_name nor _name. So with those rules in place, you get into that name collisions. At that time, FXCop (and ReSharper) would flag all field variables and tell you that you needed to use this., and it would also ding you used the m_ or _ prefixes. You had to explicitly disable the rule. The newer naming convention has been a little bit more relaxed and FXCop has been tuned back to not be as aggressive. I would assume that the same has been done with ReSharper has also been updated.

 

[LudoFromHere]

Perfect answer! I got everything. Thank you.
This was my first post. I will use the code tags, I promise.
Cheers.

 

[cjard]

I recommend to write like this:

private class Something{

  private int _someInt;

  public Something(int someInt){
    _someInt = someInt;
  }
}

If you write fields like you write arguments, you need to use `this`:

private class Something{

  private int someInt;

  public Something(int someInt){
    this.someInt = someInt;              //this.someInt is the 'private int someInt' at the top. someInt is the '...(int someInt)' just above
  }
}

The former way is less to type/less clutter and potentially avoids bugs caused by having a local and a class level var the same name, and writing one when you mean the other. By having a leading underscore I find it less likely to use the wrong one; there's no compiler error when a local variable obscures a class one and a qualifying "this" is needed

private class Something{

  private int _someInt;

  public void SomeMethod(int someInt){

    //some pages of complex code here

    someInt = someInt + 1;   //whoops, i meant to set the class level one, but forgot the `this` before `someInt = ...` 
  }
}