Действительно ли префиксы переменных ("венгерская нотация") действительно необходимы?

Question

Поскольку C# строго типизирован, нужно ли нам префиксировать переменные?

например

iUserAge
iCounter
strUsername

Я использовал префикс в прошлом, но в дальнейшем я не вижу никакой выгоды.

Answer 1

Действительно ли нужны переменные префиксы (венгерские)?

НЕТ!

Фактически, собственные рекомендации по стилю Microsoft (там, где возникла практика) теперь рекомендуют против этого. В частности, см. Раздел " Общие соглашения об именах", который включает следующий текст (не менее жирным шрифтом):

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

Answer 2

Единственные места, которые я считаю подходящими, чтобы изменить стандарты и префиксные переменные:

• контрольные имена: txtWhatever - и я вижу, что я не единственный. Приятно то, что вы можете придумать что-то вроде lblName рядом с txtName, и вам не нужно идти в направлении NameLabel/NameTextBox.

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

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

РЕДАКТИРОВАТЬ: я прочитал руководство Microsoft. Однако я считаю, что стили кодирования могут развиваться и / или "изгибаться", где это уместно. Как я упоминал выше, я обнаружил, что использование префикса подчеркивания полезно методом проб и ошибок, и это, безусловно, лучше, чем использование этого. Что бы ни было в коде.

Поддерживая "развивающуюся" теорию - еще в.NET 1.x, когда Microsoft выпустила руководящие принципы кодирования, они рекомендовали использовать корпус Camel для всего, даже для констант. Теперь я вижу, что они изменились, и советую использовать регистр Паскаля для постоянных или общедоступных полей только для чтения.

Более того, даже библиотека классов.NET Framework в настоящее время полна m_, _ и s_ (попробуйте просмотреть реализацию с помощью Reflector). Так что, в конце концов, дело за разработчиком, если в вашем проекте сохраняется согласованность.

Answer 3

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

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

i_  // input-only function parameter (most are these)
o_  // output-only function parameter (so a non-const & or * type)
io_ // bidirectional func param
_   // private member var (c#)
m_  // private member var (c++)
s_  // static member var (c++)
g_  // global (rare, typically a singleton accessor macro)

Я нашел это очень полезным. Префиксы func param особенно полезны. В глубине функции вы всегда можете сразу определить, откуда взялась эта переменная. И, как правило, мы копируем var в другое, когда хотим изменить его или изменить его значение.

Итак, вкратце: префиксы для типов не нужны в современных инструментах. IDE позаботится о том, чтобы идентифицировать и проверить это для вас. Но основанные на области префиксы очень полезны для удобочитаемости и ясности.

Есть также забавные дополнительные преимущества, такие как Intellisense. Вы можете набрать i_ ctrl-space и получить все входные параметры для функции на выбор. Или g_ ctrl-space, чтобы получить все ваши синглтоны. Это экономит время.

Answer 4

Нету. Нам когда-нибудь нужно было?

Answer 5

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

Линус хорошо подытоживает: "Кодирование типа функции в имени (так называемая венгерская нотация) повреждено мозгом - компилятор все равно знает типы и может их проверять, и это только сбивает с толку программиста"

Answer 6

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

Answer 7

Да, если бы венгерская нотация использовалась так, как она была изначально задумана, а не так, как это реализовано Microsoft. Во многом как в примере выше, который показывает текстовые поля и соответствующие метки как lblWhothing, txtWhwhat. Используйте его для определения использования переменной, а не типа. Он может предоставить информацию, чтобы узнать, что ваш номер - moneyTotal, что говорит мне больше, чем просто тип данных.

Но как часто используется? Нет.

Answer 8

Префиксы - это пережиток дней VB (и старше!), Когда венгерская нотация была королем. Это больше не так, хотя сообщество C# требует таких вещей, как использование префикса Capital I для интерфейсов (например, ILoadable).

Текущие Рекомендации Microsoft здесь.

Answer 9

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

Но как насчет печатного кода? Разве вы не проводите обзоры кода или пошаговые руководства на бумаге? Вы не используете печатный код в учебных целях? Разве вы не используете фрагменты кода для онлайн-помощи? Венгерские обозначения чрезвычайно ценны в этих случаях.

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

Answer 10

Венгерская нотация больше не нужна для идентификации типов данных, как в вашем примере строки, но она все еще может быть полезна для идентификации характеристик переменных другими способами. Вот хорошая статья, которая рассказывает о полезных способах использования венгерской нотации: http://www.joelonsoftware.com/articles/Wrong.html

Вот выдержка

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

Например, если имя переменной - rwCol, префикс - rw.

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

Он также использует пример идентификации строк с префиксом "s" или "u", чтобы определить, безопасны ли они для печати или нет, так что оператор типа print(uSomeString); может быть легко идентифицирован как неправильный.

Answer 11

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

Answer 12

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

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

Кроме того, мне нравится книга "Руководства по разработке рамок" от Addison Wesley. Он охватывает все эти руководящие принципы с аннотациями от членов команды Microsoft о том, почему они рекомендуют то, что они предлагают, и как это принято в организации.

Answer 13

Что меня интересует в этом вопросе, так это тот факт, что языки (C, а затем C++), в которых был введен префикс (т. Е. Венгерская нотация), также были строго типизированы. Насколько я знаю, это было сделано и с использованием Паскаля в Microsoft. И может показаться, что он также использовался с Mesa, языком со строгой типизацией, с которым венгерский язык мог быть знаком [;<).

В таком случае было бы справедливо разобраться с вопросом и подумать (1), какую проблему использовал префикс, чтобы помочь решить, и (2) как эта проблема ушла?

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

Answer 14

Венгерская нотация никогда не предназначалась для отображения типа данных переменной. Было неправильно понято предлагать использовать "str" или "i" для неявного определения типа. Он должен был показывать только "вид" переменной, а не "тип".

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

Я знаю, что это было связано, но прокрутите до конца статьи Джоэля для получения дополнительной информации - http://www.joelonsoftware.com/articles/Wrong.html где он говорит о том, где венгерский

Answer 15

Я использую его только в своей базе данных (PostgreSQL)

t_ for table name
v_ for view name
i_ for index name
trig_ for trigger


sp_ for stored procedure name
p_ for parameter    
v_ for variable
c_ for cursor
r_ for record

Answer 16

Точно нет. Как правило, я пришел к выводу, что это просто шум. Если вы независимый консультант или у вашей компании нет всеобъемлющего руководства по стилю, у IDesign есть отличное руководство. Просто посмотрите на правую сторону страницы, и вы сможете описать последнюю итерацию своего C# Coding Standard документа.

Стив

Answer 17

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

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

Answer 18

Общий обзор хороших соглашений см. Здесь: http://msdn.microsoft.com/en-us/library/ms229002.aspx

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

Answer 19

Нет, они нам не нужны. Я имел обыкновение следовать этому, когда в те дни мы были вынуждены следовать такого рода стандарту кодирования.

Кроме того, с помощью Intellisense, окна определения кода и инструментов рефакторинга, встроенных в VS, и других сторонних плагинов, таких как CodeRush express и Refactor Pro, работать с кодом проще без него.

Answer 20

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

Но когда я работаю с серией элементов управления пользовательским интерфейсом, будь то текстовые поля, выпадающие списки, сетки или что-то еще, я бы хотел, чтобы мой intellisense работал для меня. Поэтому для этого я обычно делаю id элемента управления с префиксом "uxSomeControlName". Таким образом, когда я ищу это текстовое поле для захвата его текстового значения, все, что мне нужно сделать, это набрать "ux", и отображаются все идентификаторы интерфейса пользователя. Нет необходимости искать txt, ddl, grd или что-либо еще.

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

Как я уже сказал, это только при работе над интерфейсом.

Answer 21

Я всегда добавляю префиксные переменные-члены к m__, а статические переменные-члены к s_. Я сталкивался с переменными статьями от людей MS, которые рекомендуют / не одобряют подход.

Я также почти уверен, что наткнулся на префикс m_ при просмотре стандартных библиотек.NET с помощью Reflector...

Answer 22

Я использую его все время, но это возможно, потому что я использую VBA с Access и Excel.

Для меня CountAll - это имя. IntCountAll - это имя с той разницей, что оно дополнительно описывает имя (никогда не предназначенное для машин, предназначенное только для людей), как sintCountAll сообщает мне его статический pintCountAll private и gintCountAll global, поэтому я использую его; это очень полезно.

• Имена элементов управления безопаснее по времени, чем вместо ControlName. У меня есть lblControlName, txtControlName, cboControlName, lstControlName и т. д., поэтому, когда я использую VBA, я просто набираю lst, и у меня есть все имена, которые мне нужны, поэтому мне не нужно запоминать точное имя что экономит мне много времени, но опять же это в основном VBA в Access и Excel.

С уважением Эмиль

Answer 23

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

Лично я считаю, что это помогает.

Answer 24

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

• Если вы поддерживаете код, который уже использует его, я бы продолжил его использовать.

• Когда правила вашей компании все еще требуют или даже предлагают это.

• Когда ваша документация имеет простой алфавитно-цифровой список переменных, она помогает группировать похожие типы.

Answer 25

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

В языках с типами со знаком и без знака или множеством похожих типов (например, short, int, long или Int8, Int16, In32) префиксы полезны, несмотря на то, что кто-либо еще имеет или скажет (и они будут, вы знаете, Это).

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

Answer 26

Решение проблемы, которой не существует.

Answer 27

Краткий ответ: нет. Но...

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

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

Кроме того, иногда я задаюсь вопросом: "Какого чёрта этот флажок был назван снова?" И мне нужно прерваться и снова заглянуть на страницу.ASPX.

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

Answer 28

Единственный префикс, который я бы рассмотрел для C#, это _ для переменных-членов, таких как

public class Test
{
    private int _id;
}

Answer 29

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

Тем не менее, я INSIST, что вы делаете префиксы элементов управления с их типом, например, txtName.