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

Question

Я никогда не был поклонником венгерской нотации, я всегда считал ее довольно бесполезной, если вы не выполняете действительно низкоуровневое программирование, но в каждом проекте C++, над которым я работал над какой-то венгерской политикой нотации , а вместе с ним и использование некоторых «не-действительно-венгерских» префиксов как m_ для полей, s_ для статики, g_ для глобалов и т. д.

Вскоре я понял, насколько бесполезно это было на C# и постепенно начал отбрасывать все мои старые привычки ... но вещь «m_». Я все еще использую префикс m_ в частных полях, потому что мне действительно очень полезно различать параметры, локали и поля.

naming conventions for fields page at MSDN говорит, что я не должен, но он не говорит, почему (например, конвенции Google обычно имеют тенденцию рационализировать их рецепты).

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

Answer 1

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

Answer 2

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

• Когда проект руководящих принципов кодирования говорят, что вы должны

Когда вы не должны:

• Когда проект руководящих принципов кодирования, что вы не должны

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

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

Answer 3

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

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

Answer 4

Я стараюсь следить за MSDN .NET library guidelines. Они включают раздел naming guidelines.

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

Answer 5

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

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

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

Answer 6

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

Answer 7

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

Если у вас статическая константа часто написана большими буквами. «static const MYCONST =« hmpf ».

Answer 8

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

Answer 9

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

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

Answer 10

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

Answer 11

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

Answer 12

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

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

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

Answer 13

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

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

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

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

Answer 14

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

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

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

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

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

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

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

Answer 15

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

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

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

Answer 16

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

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

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

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

Answer 17

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

Answer 18

Уверен, что я буду пламен для этого, но так будет.

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

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

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

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

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

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

Конвенция Переменная Нейминг

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

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

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

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

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

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

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

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

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

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

Answer 19

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

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

Answer 20

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

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

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

Answer 21

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

Answer 22

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

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

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

Answer 23

Там также может быть некоторое представление о том, чтобы почерпнуть из C++ стандарты кодирования (Sutter, Херб и Alexandrescum Андрей, 2004). Пункт № 0 озаглавлен «Не потейте мелкие вещи» (или: знайте, что не стандартизировать.) ».

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

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

Answer 24

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

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

Answer 25

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

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

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

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

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