Как вы называете аргумент конструктора и переменные-члены?

Question

Я не использую префикс при именовании внутренних переменных класса (я знаю, что некоторые делают, но я не начинаю дискуссию "почему ты ..."). Я просто предпочитаю это так. Проблема в том, что иногда одни и те же параметры передаются в конструктор, и я в итоге путаюсь, как их назвать. Например:

public class SampleClass
{
    private int classId;
    private string className;

    public SampleClass (int XclassIdX, string XclassNameX) {
        classId = XclassIdX;
        className = XclassNameX;
    }
}

Как назвать XclassIdX и XclassNameX?

Одна вещь, которую, вероятно, можно сделать, это:

public class SampleClass
{
    private int classId;
    private string className;

    public SampleClass (int classId, string className) {
        this.classId = classId;
        this.className = className;
    }
}

Просто не уверен, что это хорошая идея или есть другие более изящные способы?

Answer 1

Я думаю, что решение, которое вы описываете, где параметры конструктора имеют одинаковое имя и вы добавляете члены класса к this, просто отлично. Это ясно, это сжато, и нет никакого беспорядка относительно того, что Вы имели в виду.

Answer 2

Я просто использую подход this; тогда все мои переменные и поля отражают их намерение. Не делай вещь X - это просто уродливо; -p

Answer 3

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

Answer 4

Краткий ответ:

Префикс члены и параметры с "m_" и "p_" или "s_", если элемент статический.

Не украшайте свойства или localals , и когда вы чувствуете, что должны назвать их одинаково (игнорируя регистр), разрешите конфликт, добавив в свойствах префикс "this.".

Пояснение:

Учтите, что существует как минимум ЧЕТЫРЕ (4) различных категории читаемых / присваиваемых имен, которые необходимо различать: Локальные переменные , Переменные-члены (экземпляр и статические), Свойства , а метод Параметры . Все четыре категории могут появляться в одном кодовом блоке, и поэтому каждая из них нуждается в четких отличительных характеристиках.

Значимый префикс может одновременно различать переменные и , раскрывающие их область видимости, такую ​​как m_ (member), s_ (static), p_ (параметр), оставляя открытые свойства и локальные переменные простыми без префиксов и без беспокоиться о чувствительности к регистру. Если по какой-либо причине вы должны назвать local так же, как и свойство, без учета регистра, просто добавьте префикс в свойство this.

Конфликты именования между Локальными переменными и Параметры не встречаются, потому что их нельзя назвать одинаковыми (компилятор поймает повторяющееся определение). То же самое касается переменных-членов и Properties . Параметры и члены с префиксом «p_» и «m_» соответственно не будут конфликтовать, а конфликты между локальными элементами и свойствами без префикса можно разрешить, добавив «this». к свойствам.

Альтернативы моим предложениям не очень приятные: используйте чувствительность к регистру (плохая идея, поскольку не все языки CLR чувствительны к регистру), используйте подчеркивания сами по себе (также плохо, так как это может противоречить стандартам и не говорит вам о черт возьми), или используйте разные имена в целом (может быть трудоемким, сложным и выглядеть произвольно).

Answer 5

Вам нужно каким-то образом отделить их. Используя «это». является слабой формой венгерской нотации, так что вы можете прикусить пулю и использовать подчеркивание или «m_».

Я тоже чувствую «это». на самом деле хуже, потому что в крайних случаях (то есть в больших методах) возможно «это». будет пропущен, и неправильная переменная будет ссылаться. Я знаю, что большие методы плохие, но они естественным образом встречаются в реальных бизнес-приложениях с разработчиками разных навыков. Использование префикса для закрытых полей предотвратит этот сценарий.

Соблазнительно утверждать, что подчеркивание может быть забыто так же, как и «это». было бы. Но это неверно, потому что подчеркивание меняет имя переменной, поэтому единственное место, где она может быть забыта, - это определение, а не его использование в файле. В то время как с этим. в префиксе нет ошибки компилятора, если вы забудете об этом во время использования.

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

Answer 6

m_foo для частных пользователей
Foo для государственной собственности
foo для параметров и локальных переменных.

Я предпочитаю отличать область блока от элементов расширенной области, поэтому я придерживаюсь префикса.

Answer 7

Ставить X на ваши параметры, как это плохо. Конструктор является частью общедоступного интерфейса вашего класса, и он только запутает пользователей вашего класса. Некоторым нравится ставить переменные-члены с подчеркиванием, что гораздо лучше, так как это видно только разработчику вашего класса. В противном случае этого достаточно, как во втором примере.

Answer 8

Почему бы просто не добавить подчеркивание или однобуквенный префикс для ваших личных переменных-членов. Если вам не нравится эта идея, то, что вы сделали во втором блоке кода, в порядке.