Использование префикса для непубличных полей

Question

Я не знаю никого, кто использует «m_» для префикса непубличных полей (включая меня), но мне известно о трех причинах: должно:

1. Спецификация CLR настаивает на том, что названия свойств и соответствующие поля не отличаются только буквенным корпусом. Некоторые языки не чувствительны к регистру. Может использоваться «_», но «m_» предпочтительнее, поскольку имена должны начинаться с буквенных символов. (Это исходит от coding standards, предложенного Дэном Ригсби)
2. Простой «_» префикс не совместим с CLI, тогда как «m_» совместим с CLI.
3. Intellisense, по крайней мере в WPF от VS 2008, не различает типы, определенные в XAML, и типы, определенные в коде. «M_», используемый в коде позади, разрешит проблему.

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

p.s. Пожалуйста, не говорите мне, что «венгерский» плох, так как это предложение - в изоляции - действительно не имеет никакого отношения к венгерскому.

Answer 1

Этот вопрос задан ВО много раз, но в очередной раз это сводится к личным предпочтениям и, если вы согласны, у вас не будет проблем с любым подходом.

Насколько я знаю, большинство стандартов кодирования на C# вызывают имена переменных нижнего регистра без префикса. Лично мне не нравится этот подход, потому что ваши переменные-члены имеют тенденцию сталкиваться с параметрами метода, поэтому вам постоянно приходится квалифицировать их с помощью «этого».

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

Answer 2

В ЦБС не CLR спецификация утверждает, что открытые и защищенные члены не отличаются только регистром. Важно помнить о том, что нет необходимости делать ваши типы CLS-совместимыми, если вы не планируете использовать их в других проектах, охватывающих несколько языков. Даже тогда, если это внутренний проект, возможно, не обязательно следовать всем руководящих принципов CLS.

В любом случае это относится только к членам, потенциально видимым за пределами объявляющей сборки (другими словами, члены private и internal освобождены), это предложение не относится к непубличным полям.

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

Answer 3

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

Лично я считаю, что префикс «m_» - это отброс нажатия клавиши, но если он соответствует стандартам, то это то, к чему я буду придерживаться.

Если I писал стандарты, я бы указал, что «_» следует использовать в качестве префикса для непубличных полей.

Answer 4

Большинство людей, которых я знаю (включая меня), просто используют _ в качестве префикса для непубличных полей. Он короче набирать, и он заставляет поля отображаться вместе в intellisense. Я также считаю его более читаемым, чем m_