Соглашения об именах для аргументов конструктора?

Question

Привет, ребята, у меня всегда есть проблема с похожими именами переменных Public в классе и аргументами, которые я передаю в один и тот же конструктор классов.

Когда вы определяете новый экземплярОбъект, например, Автомобиль.Единственное, что может увидеть пользователь / программист, это имена и тип аргументов, которые он ищет.

Например:

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

Пользователь увидит эти имена и типыи мог бы знать только то, на чем они основаны, по их типу и имени, исключая любые теги XML xml.

Теперь мы всегда хотим, чтобы наши публичные переменные также были очень специфичными.* Например:

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

Теперь мы можем перейти к моему вопросу.Используя эти однострочные свойства, вместо определения частного экземпляра переменной и создания для этого свойства, как можно сделать эти имена переменных более понятными?

Я пытаюсь использовать соглашения об именах, которые другие пользователи будут использоватьнайти понятным и легко читаемым.

Прямо сейчас конструктор выглядит так:

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

Это то, что написали бы другие программисты на C #?Для этого уже существует соглашение об именах?На первый взгляд, приведенное выше утверждение выглядит немного грязно, особенно если вы опустите this.

Answer 1

Я никогда не видел параметры метода с заглавной первой буквой. Я бы предложил не делать этого, так как это не стандарт. «Это» также становится ненужным. Код ниже, по моему мнению, более читабелен. Кроме того, вы заметите, что для параметров методов вызовов .NET API их первая буква не пишется с заглавной буквы. Это относится к любому прототипу функции, а не только к конструкторам.

Редактировать: Если ваши свойства в конструкторе имеют только SET, я бы посоветовал сделать настройщики приватными (не показано в моем примере кода здесь) Еще одна полезная практика, если значения никогда не устанавливаются снова, это поддерживать их полем и делать поле доступным только для чтения. Это немного выходит за рамки вашего вопроса, но связано с определением и именованием полей и свойств.

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

Примечание: даже подсветка синтаксиса переполнения стека делает его читаемым по сравнению с кодом в исходном вопросе.

Answer 2

Имена никогда не должны быть прописными. На мой взгляд, суффикс очень необходим для различения между входным миром и свойствами класса.

Я не вижу в этом ничего плохого:

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

Answer 3

Я также использую верблюжий корпус, но предпочитаю добавлять префикс 'a' слева от имени параметра
(' a ' обозначает аргумент , этоне подразумевается как статья).
Я использую верблюжий корпус без префикса для любой переменной, локальной для процедуры.
Таким образом, вы можете на первый взгляд отличить локальную переменную от параметра.
Я понимаючто это не обычная практика.
Я использую те же соглашения, что и Дуг для полей, так что в итоге вы получите:

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

Всего два моих цента.

Answer 4

См. Соглашения об именах MS здесь и здесь .

Answer 5

Соглашение .net заключается в использовании верблюжьей оболочки для аргументов функции.Таким образом, ваш конструктор может выглядеть примерно так:

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

Кроме того, что касается свойств, у вас есть правильный регистр для них, но обычно вы можете установить поля частного экземпляра для свойств вместосвойства сами по себе - это предполагает, что у вас нет логики на стороне набора, если свойство.

Я обычно заставляю мои поля экземпляра начинаться с подчеркивания, поэтому установка поля экземпляра для свойства из вашего конструктора можетбольше похоже на следующее:

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

Также, пожалуйста, прочитайте рекомендации по дизайну MSDN для стиля для .NET Framework для дальнейшего подробного обсуждения других элементов стиля.Стандарты очень хорошо документированы, поэтому не нужно много гадать.http://msdn.microsoft.com/en-us/library/ms229042.aspx

Наслаждайтесь!