Почему я не должен снабжать префиксом свои поля? [закрытый]

Будьте функциональны.

• не используют глобальные переменные.
• не используют статические переменные.
• не используют членские переменные.

, Если Вы действительно имеете к, но только если Вы действительно имеете к, используйте одну и только одну переменную для доступа к приложению / среда.

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

Могло бы также быть некоторое понимание, которое будет подбираться от Стандарты Кодирования C++ ( Sutter, Трава и Alexandrescum Andrei , 2004). Объект № 0 наделен правом, "Не потеют маленький материал. (Или: Знайте, что не стандартизировать.)".

Они затрагивают этот конкретный вопрос немного путем высказывания, "Если Вы не можете выбрать свое собственное соглашение о присвоении имен, попробуйте... переменные члена парламента, не занимающего официального поста likeThis _ ..." (Помнят, использование начального символа подчеркивания подчиняется очень определенным правилам в C++).

Однако прежде, чем добраться там, они подчеркивают определенный уровень непротиворечивости, "... важная вещь не состоит в том, чтобы установить правило, но только согласовываться со стилем, уже используемым в файле..."

Самая близкая вещь к официальным инструкциям StyleCop, инструмент от Microsoft, которая может автоматически проанализировать Ваши исходные файлы и обнаружить нарушения от рекомендуемого стиля кодирования, и может быть выполнен из Visual Studio и/или автоматизировал сборки, такие как MSBuild.

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

Для ответа на вопрос - это не позволяет Венгерской записи, ни любых префиксов как m_ (на самом деле, это не позволяет использование подчеркиваний вообще).

Преимущество той нотации в C/C++ состояло в том, чтобы помочь видеть то, чем тип символа был, не имея необходимость идти, ищут объявление. Эти стили появились перед прибытием Intellisense и "Переходят к Определению" - мы часто должны были идти на преследование гуся, ища объявление в том, кто знает сколько заголовочных файлов. На крупном проекте это могло быть значительным раздражением, которое было достаточно плохо при рассмотрении C исходного кода, но еще хуже при выполнении использования судебной экспертизы смешанный код assembly+source и необработанный стек вызовов.

, Когда сталкивающийся с этими фактами, с помощью m_ и все другие венгерские правила начинает иметь некоторый смысл даже с обслуживанием наверху из-за того, сколько времени это сэкономило бы только в поиске типа символа при рассмотрении незнакомого кода. Теперь, конечно, у нас есть Intellisense, и "Переходят к Определению", таким образом, основная экономящая время мотивация того соглашения о присвоении имен больше не там. Я не думаю, что существует много точки в выполнении этого больше, и я обычно пытаюсь пойти с инструкциями библиотеки.NET только, чтобы быть последовательным и возможно получить немного больше поддержки инструмента.

Я не использую тот стиль больше. Это было разработано, чтобы помочь Вам видеть быстро, как использовались переменные. Более новые dev среды позволяют Вам видеть что информация путем парения мыши над переменной. Потребность в нем ушла при использовании тех более новых инструментов.

Я уверен, что буду гореться для этого, но пусть будет так.

Это назвало инструкции библиотеки.NET Microsoft, но это действительно Brad Abrams представления ( документ здесь ) - существуют другие представления с допустимыми причинами.

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

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

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

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

Ниже мои инструкции по стилю с моими причинами - я всегда ищу способы улучшить мой стиль для создания более надежный и легче поддержать код.

Переменное Соглашение о присвоении имен

у Всех нас есть наше представление о переменных соглашениях о присвоении имен. Существует много различных стилей, которые помогут произвести легко удобный в сопровождении качественный код - любой стиль, который поддерживает основную важную информацию о переменной, хорошо. Критерии определенного соглашения о присвоении имен должны быть то, что оно помогает в создании кода, который надежен и легко удобен в сопровождении. Критерии, которые не должны использоваться: это - ужасная Microsoft (т.е. Brad Abrams, который, поскольку) говорит, не используют тот стиль - Microsoft не всегда производит самый надежный код, просто смотрят на ошибки в Смешении Выражения. Это очень важно при чтении кода, что имя переменной должно немедленно передать три существенных факта о переменной: it’s определяют объем it’s типа a, ясно понимают, о каком он используется для Объема: Microsoft рекомендует положиться полностью на IntelliSense. IntelliSense является потрясающим; однако, каждый просто не делает мыши по каждой переменной, чтобы видеть, что это - объем и тип. Принятие переменной находится в объеме, который это не, может вызвать значительные ошибки. Например, если ссылочная переменная передается в в качестве параметра, и она изменена в локальном объеме, которым изменение останется после возвратов метода, которые не могут быть желаемы. Если поле или статическая переменная изменяются в локальном объеме, но каждый думает, что это - локальная переменная, неожиданное поведение могло закончиться. Поэтому чрезвычайно важно быть в состоянии просто посмотреть на переменную (не мышь) и немедленно знать, что это - объем.

следующий стиль для указания на объем предлагается; однако, любой стиль отлично хорошо пока он ясно и последовательно указывает на объем переменной: полевая переменная m_ p_ параметр передала методу s_ тип локальных переменных статической переменной: Серьезные ошибки могут произойти, если Вы полагаете, что они работают с определенным типом, когда они на самом деле работают с другим типом - снова, мы просто переделываем не мышь когда-либо переменная для определения ее типа, мы просто предполагаем, что знаем то, что ее тип и именно так ошибки создаются.

Сокращения: Сокращения являются злыми, потому что они могут иметь в виду разные вещи для различных разработчиков. Один разработчик может думать, что ведущий нижний регистр "s" означает строку, в то время как другой может думать, что это означает целое число со знаком. Сокращения являются знаком ленивого кодирования - занимают немного дополнительного времени и вводят полное имя для прояснения разработчику, который должен поддержать код. Например, различием между "ул." и "строкой" являются только три символа - не прилагает намного большего количества усилий сделать код легким поддержать.

Общие и четкие сокращения для встроенных типов данных только приемлемы, но должны быть стандартизированы в команде.

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

Порядок Частей Имени переменной: рекомендуемый порядок является описанием типа объема потому что: IntelliSense сгруппирует все подобные объемы, и в каждом объеме IntelliSense сгруппирует все подобные типы, который делает поиски легкими - пытаются найти переменную другим путем, Это делает очень легким видеть и понять объем и видеть и понять тип, Это - довольно общий стиль и легкий понять, что Это передаст примеры FxCop

: Вот несколько примеров: m_stringCustomerName p_stringCustomerDatabaseConnectionString intNumberOfCustomerRecords или iNumberOfCustomerRecords или integerNumberOfCustomerRecords Эти простые правила значительно улучшат надежность кода и пригодность для обслуживания.

Однострочные Операторы Управляющей структуры Все управляющие структуры (если, в то время как, поскольку, и т.д.) однострочные операторы должны всегда обертываться с фигурными скобками, потому что очень легко добавить новый оператор, не понимая, что данный оператор принадлежит управляющей структуре, которая повредит логику кода, не генерируя ошибок времени компиляции.

Исключение Метода, Переносящееся , Все методы должны быть обернуты с внешней выгодой попытки, которые захватывают, обеспечивают место, чтобы восстановить, определить, расположиться, зарегистрироваться, и принять решение бросать или нет. Это - непредвиденная исключительная ситуация, которые заставляют наши приложения отказывать - путем обертывания каждого метода, захватывающего все необработанные исключения, которые мы гарантируем идентификации и входу всех исключений, и мы предотвращаем наше приложение от когда-либо катастрофического отказа. Требуется немного больше работы, но результаты определенно стоят усилия.

Добавление отступа Добавление отступа не является главной проблемой; однако, четыре пробелов и не использование вкладок предлагаются. Если код печатается, первая вкладка принтера обычно значения по умолчанию к 8 пробелам. Другой разработчик склонен использовать различные размеры вкладки. Код Microsoft обычно форматируется 4 пространства поэтому, если Вы будете использовать какой-либо код Microsoft и использование кроме 4 пробелов, то код должен будет быть переформатирован. Четыре пробелов помогают и последовательный.

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

то, Что мы выбрали для нашего стандарта кода, должно использовать _ в качестве префикса для членских переменных. Одна из причин была то, что это помогает найти локальные переменные в intellisense.

, Прежде чем мы договорились о том стандарте, я использовал другой. Я не использовал префикса вообще и записал this.memberVariable в коде, чтобы показать, что я использовал членскую переменную.

Со стенографией свойства в C# 3, я нахожу, что использую намного менее явные членские переменные.

Я никогда не использую венгерских бородавок каждый раз, когда мне дают выбор. Это - дополнительный ввод и не передает значимой информации. Любой хороший IDE (и я определяю "хороший" на основе присутствия этой функции, среди других) позволит Вам иметь другую подсветку синтаксиса для статических участников, членов экземпляра, функций членства, типов, и т.д. нет никакой причины создать помехи Вашему коду информацией, которая может быть предоставлена IDE. Это - заключение к не созданию помех Вашему коду с прокомментированным старым кодом, потому что Ваша система управления версиями должна быть ответственна за тот материал.

то, к чему я привык, - то, что частные собственности добрались, маленькие underscone f.ex "представляют _name в виде строки". общедоступный получил "Имя". и входные переменные в методах добрались, строчная буква "освобождают MyMethod (имя строки)".

, если Вы получили статическую константу, часто пишется с большими буквами. static const MYCONST = "hmpf".

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

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

Во всяком случае, это составляет мои два цента.

Если я не застреваю с vi или Emacs для редактирования кода, мой IDE заботится о дифференциальном дисплее участников для меня так, я редко использую любые специальные конвенции. Это также идет для добавления префикса интерфейсов со мной или классов с C.

Кто-то, объясняет стиль.NET I-префикса в интерфейсах.:)

Существует одно важное различие между C++ и C#: поддержка Инструмента. Когда Вы будете следовать установленным инструкциям (или общие изменения), Вы доберетесь, глубокий уровень инструмента поддерживают тот C++, никогда не имел. В соответствии со стандартами позволяет инструментам делать, глубже осуществлять рефакторинг/переименовывать операции, чем Вы иначе были бы способны к. Resharper делает это. Так придерживаются одного из установленных стандартов.

Я никогда не использую их. Это поощряет неаккуратное кодирование. MSDN, кодирующий инструкции, это - то, где это в.

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

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

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

Я предпочитаю отмечать поля поддержки свойства (хотя, поскольку уже упомянутая.NET 3.0 + уменьшает потребность благодаря Автоматическим Свойствам) с подчеркиваниями, но не "m". Для одного это помещает их наверху списка InteliSense, когда я приезжаю для использования их.

я признаю, что мне нужно к повторению на инструкциях по MSDN, вещи могут измениться так быстро в эти дни.

Я пытаюсь следовать инструкции библиотеки.NET MSDN . Они включают рекомендации по именованию раздел.

, Очевидно, они вторичны к Вашим инструкциям проекта.

Я экспериментировал с m _, s _, просто _, и никакой префикс вообще. Я обосновался на использовании просто _ для всех статических переменных и переменных экземпляра. Я не нахожу важным отличить статические переменные от переменных экземпляра. В теории это звучит хорошим, на практике это не создает проблему.

коллега А однажды привел убедительный аргумент для устранения всех префиксов, мы попробовали его на одном проекте, и он работал лучше тогда, я ожидал. Я продвинул его к своему следующему проекту и стал раздраженным, что это "вмешивается" в Intellisense. Когда у Вас будет следующая ситуация

int foo;
public int Foo
{
  get { return foo; }
}

, Запуск ввести нечто предложит и переменную экземпляра и свойство. Добавление префикса переменной с подчеркиванием устраняет раздражающее двойное предложение, таким образом, я переключился назад на использование просто _.

Поскольку некоторые сослались на, в инструкциях по MS говорится:

не используют префикс для имен полей. Например, не используйте g_ или s_ для различения статичный по сравнению с нестатическими полями.

я, оказывается, соглашаюсь с этим. префиксы заставляют Ваш код посмотреть ужасное и ненужное пространство с несущественными символами. Однако часто распространено использовать поля для поддержки свойств, где и поле и свойство имели бы то же имя (при этом частное поле было бы Camel-регистром и свойством, являющимся случаем Паскаля). В VB это не работает, так как VB не чувствителен к регистру. В этом сценарии я рекомендую использование сингла _ префикс. Ни больше, ни меньше. Это просто выглядит более чистым, по моему скромному мнению.

Автореализованная функция свойства в C# 3.0 создает меньше потребности в этой конвенции так или иначе. Вместо того, чтобы писать

string m_name;
public string Name { get { return m_name; } }

или

string _Name;
public string Name { get { return _Name; } }

(или любая другая конвенция), можно теперь записать

public string Name { get; private set; }

, Так как Вам больше не нужна явная переменная запоминающего устройства, Вы больше не должны придумывать название ее; таким образом избегая этого всего обсуждения.

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

Когда Вы должны:

• , Когда Ваш проект, кодирующий инструкции, говорят, Вы должны

, Когда Вы не были должны:

• , Когда Ваш проект, кодирующий инструкции, говорят, Вы не были должны

, Если у Вас еще нет инструкций, Вы свободны выбрать независимо от того, что Вы или Ваша команда хотите и чувствуете себя больше всего комфортно с. Лично при кодировании C++ я склонен использовать m_ для участников, он действительно помогает. При кодировании на других языках, особенно те, которые не имеют истинных классов (как JavaScript, Lua) я не делаю.

Короче говоря я не полагаю, что существует "право" и "неправильный" путь.

Как @John упоминания Крафта, нет никакого "корректного" ответа. MattJ является самым близким - необходимо всегда следовать инструкциям по стилю компании. Когда в Риме, и все это.

Что касается моего личного мнения, так как это требуется здесь, я голосую за то, чтобы Вы отбросили m_ полностью.

я полагаю, что лучший стиль является тем, где все участники PascalCased, независимо от видимости (который означает даже private участники), и все аргументы camelCased. Я не повреждаю этот стиль.

я могу понять требование снабдить префиксом поле запоминающего устройства свойства; в конце концов, необходимо ли дифференцироваться между полем и свойством, правильно? Я соглашаюсь, Вы должны. Но используйте постфикс.

Вместо m_MyProperty (или даже _MyProperty, который я видел и даже продвинул когда-то давно), используйте MyPropertyValue. Легче читать и понять и - что еще более важно - это близко к Вашему исходному имени свойства в intellisense.

В конечном счете, это - причина, я предпочитаю постфикс. Если я хочу получить доступ MyPropertyValue использование intellisense Вы (обычно) тип "118", так как к тому времени Вы достаточно близки, что только MyProperty и MyPropertyValue находятся в списке. Если Вы захотите получить доступ m_MyProperty использование intellisense, то Вы будете иметь к типу "1112".

, который Это об экономике нажатия клавиши, по-моему.

Вот несколько причин использовать _ (а не m_).

(1) Многие ребята из BCL делают это, несмотря на руководство MS по именованию. (Посмотрите их блог .) Эти ребята пишут фреймворк, поэтому у них есть хорошие привычки, которые стоит копировать. Некоторые из наиболее полезных примеров кода в MSDN написаны ими, поэтому в них используется соглашение о подчеркивании. Это де-факто отраслевой стандарт.

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

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

Сноска: «m» для члена в m_ излишне в нашем использовании здесь, но это был нижний регистр, потому что одна из идей во многих из этих старых соглашений об именах заключалась в том, что имена типов начинались с верхнего регистра, а имена экземпляров начинались с нижний регистр. Это не относится к .NET, поэтому вдвойне избыточно. Также венгерская нотация иногда была полезна со старыми компиляторами C (например, целочисленное преобразование или приведение указателей и арифметика), но даже в C ++ ее полезность была уменьшена при работе с классами.