Почему мне не следует префиксировать поля?[закрыто]
https://stackoverflow.com/questions/659552
-
20-08-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Я никогда не был поклонником венгерской нотации, я всегда находил ее довольно бесполезной, если только вы не занимаетесь программированием действительно низкого уровня, но в каждом проекте C++, над которым я работал, применялась какая-то политика венгерской нотации, и при этом используются некоторые «не совсем венгерские» префиксы, такие как m_ для полей, s_ для статики, g_ для глобальных переменных и так далее.
Вскоре я понял, насколько это бесполезно в C#, и постепенно начал отказываться от всех своих старых привычек...но вещь «m_».Я до сих пор использую префикс m_ для частных полей, потому что считаю его очень полезным для возможности различать параметры, локальные переменные и поля.
А соглашения об именах для страницы полей в MSDN говорит, что я не должен, но не говорит, почему (например,Соглашения Google обычно имеют тенденцию рационализировать свои рецепты).
Есть ли причины, по которым мне не следует этого делать, или это только вопрос стиля.Если последнее, то считаются ли префиксы плохим стилем и могу ли я ожидать негативной реакции со стороны других людей, работающих над базой кода?
Решение
Мне нравится префикс нижней панели для полей участников. В основном мне это нравится, потому что таким образом все мои поля-члены отображаются в алфавитном порядке перед моими методами на панели мастера в верхней части экрана.
Другие советы
Когда вам следует:
- Когда в руководствах по кодированию вашего проекта говорится, что вам следует
Когда не следует:
- Когда в правилах кодирования вашего проекта говорится, что не следует
Если у вас еще нет каких-либо рекомендаций, вы можете выбрать то, что хотите вы или ваша команда, и чувствовать себя наиболее комфортно.Лично при программировании на C++ я обычно использую m_ для членов, это действительно помогает.При кодировании на других языках, особенно без настоящих классов (например, Javascript, Lua), я этого не делаю.
Короче говоря, я не верю, что существует «правильный» и «неправильный» путь.
Функция автоматической реализации свойств в 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; }
Поскольку вам больше не нужна явная переменная резервного хранилища, вам больше не нужно придумывать для нее имя;таким образом избегая всей этой дискуссии.
Очевидно, что этот аргумент неприменим, когда вам действительно нужно явное резервное хранилище, например, для выполнения проверки.
Как уже упоминали некоторые, в руководствах MS говорится:
Не используйте префикс для имен полей. Например, не используйте g_ или s_ для различать статический и нестатический поля.
Я согласен с этим. префиксы делают ваш код уродливым и тратят пространство с несущественными символами. Сказав это, часто используют поля для поддержки свойств, где и у поля, и у свойства будет одно и то же имя (частное поле - это верблюжий случай, а свойство - случай Паскаля). В VB это не работает, так как VB не чувствителен к регистру. В этом случае я рекомендую использовать один префикс _. Не больше, не меньше. Это выглядит чище, ИМХО.
Я экспериментировал с m_, s_, просто _ и без префикса вообще. Я остановился на использовании только _ для всех статических и переменных экземпляра. Я не считаю важным отличать статические переменные от переменных экземпляра. В теории это звучит хорошо, на практике это не создает проблемы.
Сотрудник однажды выступил с убедительным аргументом об устранении всех префиксов, мы опробовали его на одном проекте, и он работал лучше, чем я ожидал. Я перенес его в свой следующий проект и стал раздражаться, что он & Мешает & Quot; с Intellisense. Когда у вас следующая ситуация
int foo;
public int Foo
{
get { return foo; }
}
При вводе foo будут предложены как переменная экземпляра, так и свойство Префикс переменной с подчеркиванием устраняет раздражающее двойное предложение, поэтому я вернулся к использованию только _.
Я стараюсь следовать правилам библиотеки MSDN .NET . Они включают в себя правила именования .
Очевидно, это второстепенные принципы вашего проекта.
Я предпочитаю отмечать поля поддержки свойств (хотя, как уже упоминалось, .NET 3.0+ уменьшает необходимость благодаря автоматическим свойствам), подчеркивания, но не " m " ;. С одной стороны, он помещает их в начало списка InteliSense, когда я их использую.
Я признаю, что мне нужно освежить рекомендации по MSDN, в наши дни все может измениться так быстро.
С такими инструментами, как resharper, действительно нет причин для префиксов. Также, если вы пишете короткие методы, вы должны очень быстро определить, откуда берется var. Наконец, я полагаю, что я не вижу необходимости различать статические значения или нет, потому что resharper снова изменит его, если вы попытаетесь сделать что-то, чего не можете. Даже без resharper вы, вероятно, сохранены компилятором.
Я всегда добавляю переменные-члены к m _ , а статические переменные к s _ по тем же причинам, которые вы указали. Некоторые люди ставят переменные-члены с подчеркиванием, но я всегда нахожу это немного странным (но это всего лишь личное предпочтение).
Большинство людей, с которыми я работаю, используют префикс m_ / s_. Я действительно не думаю, что это имеет большое значение, что вы используете, если вы последовательны.
Я никогда не использую их. Это поощряет небрежное кодирование. Руководство по кодированию MSDN, вот где оно.
Вот несколько причин использовать _ (а не m _).
(1) Многие ребята из BCL делают это, несмотря на руководство MS по именованию. (Посетите их блог .) Эти ребята пишут основы, поэтому у них есть некоторые полезные привычки стоит скопировать. Некоторые из наиболее полезных примеров кода на MSDN написаны ими, поэтому используется соглашение о подчеркивании. Это де-факто отраслевой стандарт.
(2) Отдельное подчеркивание - это заметный, но ненавязчивый способ устранения неоднозначности переменных метода и класса, просто читая источник. Это помогает людям понять новый (или старый) код с первого взгляда при его чтении. Да, вы можете навести курсор мыши, чтобы увидеть это в IDE, но мы не должны этого делать. Возможно, вы захотите прочитать его в текстовом редакторе или, скажете вы, на бумаге.
(3) Некоторые говорят, что вам не нужен префикс, так как методы будут короткими, и позже, если потребуется, вы можете изменить поле на автоматически реализуемое свойство. Но в реальном мире методы настолько длинны, насколько это необходимо, и между полями и свойствами есть важные различия (например, сериализация и инициализация).
Сноска: " m " здесь член в m_ является избыточным при нашем использовании, но это был нижний регистр, потому что одна из идей во многих из этих старых соглашений об именах заключалась в том, что имена типов начинаются с верхнего регистра, а имена экземпляров начинаются с нижнего регистра. Это не относится к .NET, поэтому это вдвойне избыточно. Также венгерская нотация иногда была полезна со старыми компиляторами C (например, целочисленное или приведение указателей и арифметика), но даже в C ++ ее полезность уменьшалась при работе с классами.
Между C ++ и C # есть одно важное отличие: поддержка инструментов. Когда вы будете следовать установленным рекомендациям (или распространенным вариантам), вы получите глубокий уровень поддержки инструментов, которого C ++ никогда не имел. Следование стандартам позволяет инструментам выполнять операции рефакторинга / переименования глубже, чем вы могли бы. Решарпер делает это. Так что придерживайтесь одного из установленных стандартов.
Как упоминает @John Kraft, " правильный " нет; ответ. MattJ - самый близкий - вы всегда должны следовать правилам стиля вашей компании. Когда в Риме и все такое.
Что касается моего личного мнения, так как оно здесь требуется, я голосую за то, чтобы вы отбросили m_ полностью.
Я считаю, что лучший стиль - это тот, где все участники PascalCased, независимо от видимости (это означает, что даже private участники), а все аргументы camelCased. Я не нарушаю этот стиль.
Я понимаю желание поставить префикс свойства в хранилище; В конце концов, вы должны различать поле и собственность, верно? Я согласен, вы должны. Но используйте пост-исправление.
Вместо m_MyProperty (или даже _MyProperty, который я когда-то видел и даже рекламировал), используйте MyPropertyValue. Его легче читать и понимать, и, что более важно, он близок к исходному имени свойства в intellisense.
В конечном счете, именно поэтому я предпочитаю постфикс. Если я хочу получить доступ к My <down-arrow> <tab> с помощью intellisense, вы (как правило) набираете & Quot; MyProperty & Quot; поскольку к тому времени вы достаточно близки, чтобы в списке были только m_My <tab> и <=> , Если вы хотите получить доступ к <=> с помощью intellisense, вам нужно будет ввести & Quot; <=> & Quot;.
Речь идет об экономике нажатия клавиш, на мой взгляд.
Я никогда не делаю этого, и причина в том, что я стараюсь держать свои методы короткими. Если я вижу весь метод на экране, я могу видеть параметры, я могу видеть местных жителей и, таким образом, я могу сказать, что принадлежит классу, а что является параметром или локальным.
Я обычно называю свои параметры и локальные имена, используя определенные обозначения, но не всегда. Я ничто, если не противоречие. Я полагаюсь на то, что мои методы короткие, и стараюсь не давать им делать X, Y и Z, когда они должны делать только X.
Во всяком случае, это мои два цента.
Если я не использую vi или Emacs для редактирования кода, моя среда IDE позаботится о дифференциальном отображении членов, поэтому я редко использую какие-либо специальные соглашения. Это также касается префиксов интерфейсов с I или классов с C.
Кто-нибудь, пожалуйста, объясните .NET-стиль I-префикса на интерфейсах. :)
я привык к тому, что частные свойства получили небольшое занижение f.ex " string _name " ;. публичный получил " имя " ;. и входные переменные в методах получили маленькую букву " void MyMethod (имя строки) ".
если у вас есть статический const, то он часто пишется большими буквами. static const MYCONST = "hmpf".
Я никогда не использую венгерские бородавки, когда мне предоставляется выбор. Это дополнительный набор текста и не несет никакой значимой информации. Любая хорошая IDE (и я определяю & Quot; хорошая & Quot; в зависимости от наличия этой функции, среди прочего) позволит вам иметь различную подсветку синтаксиса для статических членов, членов экземпляров, функций-членов, типов и т. Д. Нет причин загромождать ваш код информацией, которую может предоставить IDE. Это следствие того, чтобы не загромождать ваш код закомментированным старым кодом, потому что ваша система управления версиями должна отвечать за это.
Лучший способ - договориться о стандарте со своими коллегами и придерживаться его. Это не обязательно должен быть метод, который лучше всего работает для всех, просто согласиться с одним методом важнее, чем тот, с которым вы действительно согласны.
То, что мы выбрали для нашего стандарта кода, это использование _ в качестве префикса для переменных-членов. Одной из причин было то, что он облегчает поиск локальных переменных в intellisense.
Прежде чем мы договорились об этом стандарте, я использовал другой. Я вообще не использовал префиксы и написал this.memberVariable в коде, чтобы показать, что я использую переменную-член.
С сокращением свойства в C # 3 я нахожу, что я использую гораздо менее явные переменные-члены.
Наиболее близким к официальным рекомендациям является StyleCop , инструмент от Microsoft, который может автоматически анализировать исходные файлы и выявляют нарушения из рекомендованного стиля кодирования, и их можно запускать из Visual Studio и / или из автоматических сборок, таких как MSBuild.
Мы используем его в наших проектах, и это помогает сделать стиль и разметку кода более согласованными между разработчиками, хотя имейте в виду, что довольно нужно немного привыкнуть!
Чтобы ответить на ваш вопрос - он не допускает ни венгерской нотации, ни префиксов вроде m_ (на самом деле, он вообще не позволяет использовать подчеркивание).
Я больше не использую этот стиль. Он был разработан, чтобы помочь вам быстро увидеть, как используются переменные. Более новые среды разработки позволяют вам увидеть эту информацию, наведя указатель мыши на переменную. Потребность в этом исчезла, если вы используете эти новые инструменты.
Также можно получить некоторые сведения из Стандартов кодирования C ++ ( Sutter, Herb и Alexandrescum Andrei , 2004). Пункт № 0 имеет право & "Не парься по мелочам. (Или: знать, что не нужно стандартизировать.) & Quot;.
Они немного затрагивают этот конкретный вопрос, говоря & "Если вы не можете определиться с собственным соглашением об именах, попробуйте ... закрытые переменные-члены likeThis _ ... < !> Quot; (Помните, что использование начального подчеркивания подчиняется очень специфическим правилам в C ++).
Однако, прежде чем попасть туда, они подчеркивают определенный уровень согласованности & ... важно не устанавливать правило, а просто соответствовать стилю, уже используемому в файле ... Quot &;
Преимущество этой нотации в C / C ++ заключалось в том, чтобы упростить просмотр типа символа без необходимости искать объявление. Эти стили появились до появления Intellisense и & Quot; Перейти к определению & Quot; - нам часто приходилось искать погоню за декларацией, кто знает, сколько заголовочных файлов. В большом проекте это может быть серьезным раздражением, что достаточно плохо, если смотреть на исходный код на языке C, но еще хуже, когда выполняется криминалистика с использованием смешанной сборки + исходного кода и необработанного стека вызовов.
Когда сталкиваешься с этими реалиями, использование m_ и всех других венгерских правил начинает иметь некоторый смысл, даже с учетом накладных расходов на обслуживание, из-за того, сколько времени это сэкономит, просто просматривая тип символа при просмотре незнакомого кода. Теперь, конечно, у нас есть Intellisense и & Quot; Go to Definition & Quot; так что основной мотивации для экономии времени в этом соглашении об именах больше нет. Я не думаю, что в этом больше есть смысл, и я обычно стараюсь придерживаться рекомендаций библиотеки .NET, чтобы быть последовательными и, возможно, получить немного больше поддержки инструментов.
Я уверен, что меня за это раскритиковают, но пусть будет так.
Это называется рекомендациями Microsoft по библиотекам .NET, но на самом деле это Брэд Абрамс Просмотры (документ здесь) - есть и другие мнения, имеющие веские причины.
Люди склонны следовать мнению большинства, а не иметь веских причин для выбора определенного стиля.
Важным моментом является оценка того, почему используется тот или иной стиль и почему он предпочтительнее другого стиля - другими словами, у вас должна быть причина для выбора стиля, а не только потому, что все говорят, что это то, что нужно делать - думайте сами.
Основной причиной отказа от использования старого венгерского стиля было использование сокращений, которые были разными для каждой команды и которые трудно выучить - эту проблему легко решить, отказавшись от сокращений.
По мере изменения доступных инструментов разработки стиль должен меняться на тот, который имеет наибольший смысл, но для каждого элемента стиля должна быть веская причина.
Ниже приведены мои рекомендации по стилю с указанием причин: я всегда ищу способы улучшить свой стиль, чтобы создавать более надежный и простой в обслуживании код.
Соглашение об именах переменных
У каждого из нас есть свое мнение относительно соглашений об именах переменных.Существует множество различных стилей, которые помогут создавать удобный в сопровождении качественный код — подойдет любой стиль, поддерживающий основную важную информацию о переменной.Критерием конкретного соглашения об именах должно быть то, что оно помогает создавать надежный и простой в сопровождении код.Критерии, которые не следует использовать:Это уродливая Microsoft (т.е.Брэд Абрамс) советует не использовать этот стиль — Microsoft не всегда создает самый надежный код, просто посмотрите на ошибки в Expression Blend.При чтении кода очень важно, чтобы имя переменной сразу же сообщало три важных факта о переменной:Это область применения, это четко понимает, что он используется для областей:Microsoft рекомендует полностью полагаться на IntelliSense.IntelliSense — это потрясающе;однако просто не нужно наводить указатель мыши на каждую переменную, чтобы увидеть ее область действия и тип.Если предположить, что переменная находится в области, которой она не принадлежит, это может привести к серьезным ошибкам.Например, если ссылочная переменная передается в качестве параметра и изменяется в локальной области, это изменение сохранится после возврата метода, что может быть нежелательно.Если поле или статическая переменная изменены в локальной области, но предполагается, что это локальная переменная, это может привести к неожиданному поведению.Поэтому чрезвычайно важно иметь возможность просто взглянуть на переменную (не наведя курсор мыши) и мгновенно узнать ее область действия.
Предлагается следующий стиль обозначения области действия;однако подойдет любой стиль, если он четко и последовательно указывает область действия переменной:Переменная переменная поля M_ P_ Параметр, передаваемый методу S_ Статическая переменная, локальная переменная тип:Серьезные ошибки могут возникнуть, если кто-то считает, что работает с определенным типом, хотя на самом деле он работает с другим типом - опять же, мы просто не наводим курсор мыши на переменную, чтобы определить ее тип, мы просто предполагаем, что знаем ее тип и именно так создаются ошибки.
Сокращения:Аббревиатуры — это зло, потому что для разных разработчиков они могут означать разные вещи.Один разработчик может подумать, что начальная строчная буква «s» означает строку, а другой может подумать, что это означает целое число со знаком.Аббревиатуры — признак ленивого кодирования — потратьте немного больше времени и введите полное имя, чтобы разработчик понял, что ему приходится поддерживать код.Например, разница между «str» и «string» составляет всего три символа — не нужно много усилий, чтобы сделать код простым в сопровождении.
Общие и понятные сокращения допустимы только для встроенных типов данных, но должны быть стандартизированы внутри команды.
Самодокументирующийся код:Добавление четкого описания к имени переменной упрощает чтение и понимание кода другим разработчиком — сделайте имя настолько понятным, чтобы менеджер группы мог читать и понимать код, не будучи разработчиком.
Порядок частей имени переменной:Рекомендуемый порядок — описание типа области действия, поскольку:Intellisense будет сгруппировать все схожие сферы, и в каждом сфере Intellisense будет сгруппировать все похожие типы, что облегчает поиск - попробуйте найти переменную наоборот. стиль и простой для понимания, он пройдет fxcop
Примеры:Вот несколько примеров:M_STRINGCUSTOMERNAME P_STRINGCUSTOMERDATABASECONNECTIONSTRING IntnumberOfCustomerRecords или inumberOfCustomerRecords или IntegerNumberOfCustomerRecords Эти простые правила значительно улучшат надежность кода и обслуживаемость.
Структура управления операторами отдельной линии все структуры управления (если, в то время как, для и т. Д.) Определения отдельной линии всегда должны быть завернуты в скобки, потому что очень легко добавить новое утверждение, не понимая, что данное оператор принадлежит структуре управления, которая будет Разбейте логику кода, не генерируя ошибки времени компиляции.
Обертывание исключений методаВсе методы должны быть обернуты внешней ловушкой try-catch, предоставляющей место для восстановления, идентификации, обнаружения, регистрации и принятия решения о выдаче или нет.Именно неожиданное исключение приводит к сбою наших приложений — оборачивая каждый метод, перехватывающий все необработанные исключения, мы гарантируем выявление и регистрацию всех исключений и предотвращаем сбой нашего приложения.Это потребует немного больше усилий, но результат стоит затраченных усилий.
ОтступОтступы не являются серьезной проблемой;однако рекомендуется использовать четыре пробела и не использовать табуляцию.Если код печатается, первая вкладка принтера обычно содержит 8 пробелов.Разные разработчики, как правило, используют разные размеры вкладок.Код Microsoft обычно имеет отступ в 4 пробела, поэтому, если кто-то использует какой-либо код Microsoft и использует другие пробелы, кроме 4, код необходимо будет переформатировать.Четыре пробела делают это простым и последовательным.
Если вы не пишете код в соответствии с определенным руководством, вы должны продолжать использовать вашу фактическую нотацию m_ и менять ее, если так указано в рекомендациях по кодированию проекта.
Будьте функциональными.
- Не используйте глобальные переменные.
- Не используйте статические переменные.
- Не используйте переменные-члены.
Если вам действительно нужно, но только если вам действительно нужно, используйте одну и только одну переменную для доступа к вашему приложению/среде.
