Naming conventions for Constructor Arguments?

Question

I always have an issue with similarities between the names of the Public variables in a class and the arguments I am passing into the same classes constructor.

When you are defining a new instance of an object, for example, Car. The only thing that the user/programmer can see is the names and type of the arguments that is it looking for.

For Example:

public Car(Color BodyColor, int NumOfDoors, int SizeOfWheels)
{
}

The user would see these names and types, and would only be able to know what they are based on their type and name, exluding any xml summary tags.

Now, we always want our public variables to be very specific as well.

For Example:

public Color BodyColor { get; set; }
public int NumOfDoors { get; set; }
public int SizeOfWheels { get; set; }

Now, we can get to my question. Using these one-line properties, instead of defining a private instance of the variable and creating the property for that, how does one make these variable names more clear?

I am trying to use naming conventions that other users will find understandable and easy to read.

Right now the constructor looks like

public Car(Color BodyColor, int NumOfDoors, int SizeOfWheels)
{
     this.BodyColor = BodyColor;
     this.NumOfDoors = NumOfDoors;
     this.SizeOfWheels = SizeOfWheels;
}

Is this what other C# programmers would write? Is there a naming convention that already exists for this? At first glance, the above statement looks a tad messy, especially if you omit the this.

Answer 1

I have never seen method parameters with the first letter capitalized. I would suggest not doing this as it is not a standard. The 'this' also becomes unnecessary. The below code is more readable, in my opinion. Also, you will notice that .NET API calls' method parameters do not have their first letter capitalized. This applies to any function prototype, not just constructors.

Edit : If your properties are only SET in the constructor, I would suggest making the setters private (not shown in my example code here). Another good practice, if the values are never set again, is to have them backed by a field, and make the field read-only. That is a bit out of scope of your question, but is related to defining and naming fields and properties.

public Car(Color bodyColor, int numOfDoors, int sizeOfWheels)
{
     BodyColor = bodyColor;
     NumOfDoors = numOfDoors;
     SizeOfWheels = sizeOfWheels;
}

Note: Even the Stack Overflow syntax highlighting makes it readable compared to the code in your original question.

Answer 2

I use camel casing as well, but prefer to add an 'a' prefix on the left of parameter name
( the ' a ' stands for argument , it is not meant as an article ) .
I use camel casing without any prefix for any variable local to the routine .
Doing so, you can tell at first glance a local variable from a parameter .
I understand that this is not common practice, though .
I use the same conventions as Doug for fields, so you'll end up with :

public Car(Color aBodyColor, int aNumOfDoors, int aSizeOfWheels)
{
     this._bodyColor = aBodyColor;
     this._numOfDoors = aNumOfDoors;
     this._sizeOfWheels = aSizeOfWheels;
}

Just my two cents .

Answer 3

The .net convention is to use camel casing for function arguments. So your constructor might look something like the following:

public Car(Color bodyColor, int numOfDoors, int sizeOfWheels)
{
}

Also as far as the properties go, you have the casing correct for those, but typically you might set the private instance fields for the properties instead of the properties themselves directly - that assumes that you don't have any logic in the set side if the property.

I usually make my instance fields start with an underscore so setting the instance field for the property from your constructor might look more like the following:

public Car(Color bodyColor, int numOfDoors, int sizeOfWheels)
{
     this._bodyColor = bodyColor;
     this._numOfDoors = numOfDoors;
     this._sizeOfWheels = sizeOfWheels;
}

Also please read the MSDN Design guidelines for style for the .NET framework for a further detailed discussion of other style elements. The standards are very well documented - so there really shouldn't be much guess work. http://msdn.microsoft.com/en-us/library/ms229042.aspx

Enjoy!

Answer 4

请参阅此处和此处的MS 命名约定。

Answer 5

Names should definetively never be upper case. A suffix is, on my opinion, very needed to differentiate between those the input world and the class properties.

I don't see anything bad about this:

public Car(Color bodyColorInput, int numOfDoorsInput, int sizeOfWheelsInput)
{
     this.BodyColor = bodyColorInput;
     this.NumOfDoors = numOfDoorsInput;
     this.SizeOfWheels = sizeOfWheelsInput;
}