Почему я не должен префикс моих полей?

Ответ 1

Мне нравится префикс underbar для полей member. В основном мне это нравится, потому что таким образом все поля моего члена отображаются в алфавитном порядке перед моими методами на панели мастера в верхней части экрана.

Ответ 2

Когда вам нужно:

• Когда ваши рекомендации по кодированию проекта говорят, что вы должны

Если вы не должны:

• Когда ваши рекомендации по кодированию проекта говорят, что вы не должны

Если у вас пока нет каких-либо указаний, вы можете выбрать то, что вам или вашей команде хотите, и чувствовать себя наиболее комфортно. Лично при кодировании С++ я стараюсь использовать m_ для членов, но это помогает. При кодировании на других языках, особенно тех, у кого нет истинных классов (например, Javascript, Lua), я этого не делаю.

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

Ответ 3

Автоматически реализованная функция свойства в С# 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; }

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

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

Ответ 4

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

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

Я согласен с этим. префиксы делают ваш код похожим на уродливое и ненужное пространство с несущественными символами. Сказав это, часто часто используют поля для возврата свойств, где и поле, и свойство имеют одно и то же имя (с частным полем, являющимся случаем верблюда, а свойство - паскальным). В VB это не работает, поскольку VB не чувствителен к регистру. В этом случае я рекомендую использовать один префикс. Не больше, не меньше. Он просто выглядит чище, ИМХО.

Ответ 5

Я экспериментировал с m_, s_, просто _ и без префикса. Я решил использовать только _ для всех переменных static и экземпляра. Я не считаю важным отличать статические переменные от переменных экземпляра. Теоретически это звучит хорошо, на практике это не создает проблемы.

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

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

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

Ответ 6

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

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

Ответ 7

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

Я признаю, что мне нужно разобраться с рекомендациями по MSDN, в наши дни все может измениться.

Ответ 8

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

Ответ 9

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

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

Ответ 10

Я никогда их не использую. Он поощряет неаккуратное кодирование. Руководства по кодированию MSDN, где он находится.

Ответ 11

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

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

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

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

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

Ответ 12

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

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

Ответ 13

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

Ответ 14

Как отмечает @John Kraft, нет "правильного" ответа. MattJ является самым близким - вы всегда должны следовать рекомендациям вашего фирменного стиля. Когда в Риме и все такое.

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

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

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

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

В конечном счете, причина, по которой я предпочитаю постфикс. Если я хочу получить доступ к MyPropertyValue, используя intellisense, вы (обычно) наберите "My <down-arrow> <tab>", так как к тому времени вы достаточно близки, чтобы в списке были только MyProperty и MyPropertyValue. Если вы хотите получить доступ к m_MyProperty с помощью intellisense, вам нужно будет ввести "m_My <tab>".

Это о механизме нажатия клавиши, на мой взгляд.

Ответ 15

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

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

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

Ответ 16

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

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

Ответ 17

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

Ответ 18

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

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

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

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

Ответ 19

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

Он назывался руководящими принципами библиотеки Microsoft.NET, но на самом деле это взгляды Брэда Абрамса (документ здесь) - есть и другие взгляды с уважительными причинами.

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

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

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

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

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

Соглашение об именовании переменных

У всех нас есть свой взгляд на соглашения об именовании переменных. Есть много разных стилей, которые помогут создать легко поддерживаемый качественный код - любой стиль, который поддерживает основную важную информацию о переменной, в порядке. Критерии для конкретного соглашения об именах должны заключаться в том, что оно помогает создавать надежный и легко обслуживаемый код. Критерии, которые не следует использовать, таковы: уродливый Microsoft (то есть Брэд Абрамс) говорит, что не используйте этот стиль - Microsoft не всегда создает самый надежный код, просто посмотрите на ошибки в Expression Blend. При чтении кода очень важно, чтобы имя переменной мгновенно передавало три существенных факта о переменной: ее область действия, ее тип и четкое понимание того, что она используется для Scope: Microsoft рекомендует полностью полагаться на IntelliSense. IntelliSense потрясающий; однако, просто не наведите курсор мыши на каждую переменную, чтобы увидеть ее область видимости и тип. Предполагая, что переменная находится в области видимости, она не может вызвать существенных ошибок. Например, если в качестве параметра передается ссылочная переменная, и она изменяется в локальной области, то это изменение останется после возврата метода, что может быть нежелательным. Если поле или статическая переменная изменяются в локальной области видимости, но считается, что это локальная переменная, может возникнуть непредвиденное поведение. Поэтому крайне важно иметь возможность просто посмотреть на переменную (не наведя курсор мыши) и мгновенно узнать ее область действия.

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

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

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

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

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

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

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

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

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

Ответ 20

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

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

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

Ответ 21

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

Ответ 22

Также может быть некоторое понимание, которое можно почерпнуть из стандартов Coding Coding ( Sutter, Herb и Alexandrescum Andrei, 2004). Пункт № 0 озаглавлен "Не потейте мелкие вещи" (или: знайте, что не стандартизировать.) ".

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

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

Ответ 23

Преимущество этих обозначений в C/С++ заключалось в том, чтобы упростить просмотр типа символа без необходимости поиска декларации. Эти стили появились до прибытия Intellisense и "Go to Definition" - нам часто приходилось идти на охоту за гусями, ища декларацию, в которой кто знает, сколько заголовков. В большом проекте это может быть значительным раздражением, которое было достаточно плохо, если смотреть на исходный код C, но еще хуже, когда вы делаете экспертизу, используя смешанный сборник + исходный код и сырой стек вызовов.

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

Ответ 24

Если вы не кодируете конкретную директиву, вы должны продолжать использовать свою фактическую нотацию m_ и изменить ее, если это руководство написано так.

Ответ 25

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

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

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