Венгерская запись в C#

У Джоэла Спольски есть действительно хорошая статья на эту тему. Вкратце, есть два типа венгерской нотации, которые используются на практике.

Первым является «Системный венгерский», где вы указываете тип переменной с помощью префикса. Такие вещи, как "str" ​​для строки. Это почти бесполезная информация, тем более что современные IDE все равно сообщат вам тип.

Второй - «Apps Hungarian», в котором вы указываете назначение переменной с префиксом. Наиболее распространенным примером этого является использование «m_» для указания переменных-членов. Это может быть чрезвычайно полезно, если все сделано правильно.

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

Самая интересная часть этой статьи - то, что оригинальный изобретатель венгерской нотации Чарльз Симони создал «Apps Hungarian», но его статья была ужасно неверно истолкована и мерзость "Systems Hungarian" был создан в результате.

At some point, you're likely to have a property

public string ExecutablePath { ... }

(not that you should try to avoid abbreviations like "Exe" too). That being the case, your question might then be moot much of the time as you can use C# 3.0's auto-properties

public string ExecutablePath { get; set; }

you now no longer have to come up with a name for the backing store variable. No name, no question/debate about naming conventions.

Obviously, auto-implemented properties aren't always appropriate.

If you hold the pointer over the variable in VS it will tell you what type of variable it is, so there is no reason to go with these cryptic variable names, esp as people that are coming from other languages may need to maintain the code and it will be an obstacle to easy reading.

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

Единственные две области, где в настоящее время я вижу любую форму венгерской нотации:

• Переменные-члены класса с ведущий символ подчеркивания (например, _someVar )
• Имена элементов управления WinForms и WebForms ( btn для кнопки, фунт для ярлыка и т. д.)

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

, если вы не используете текстовый редактор вместо VS IDE, для венгерской нотации мало пользы, и она скорее препятствует, чем улучшает читаемость

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

You're certainly not the only person, but I do hope you're part of a declining trend :)

The problem with Hungarian notation is that it's trying to implement a type system via naming conventions. This is extremely problematic because it's a type system with only human verification. Every human on the project has to agree to the same set of standards, do rigorous code reviews and ensure that all new types are assigned the appropriate and correct prefix. In short, it's impossible to guarantee consistency with a large enough code base. At the point there is no consistency why are you doing it?

Furthermore tools don't support Hungarian notation. That might seem like a stupid comment on the surface but consider refactoring for instance. Each refactoring in a Hungarian naming convention system must be accompanied with a mass rename to ensure that prefixes are maintained. Mass renames are susceptible to all sorts of subtle bugs.

Instead of using names to implement a type system, just rely on the type system. It has automatic verification and tool support. Newer IDE's make it much easier to discover a variable's type (intellisense, hover tips, etc ...) and really remove the original desire for Hungarian Notation.

Hungarian notation is a terrible mistake, in any language. You shouldn't use it in C++ either. Name your variables so you know what they're for. Don't name them to duplicate type information that the IDE can give you anyway, and which may change (and is usually irrelevant anyway. If you know that something is a counter, then it doesn't matter whether it's an int16, 32 or 64. You know that it acts as a counter, and as such, any operation that's valid on a counter should be valid. Same argument for X/Y coordinates. They're coordinates. It doesn't matter if they're floats or doubles. It may be relevant to know whether a value is in units of weight, distance or speed. It doesn't matter that it's a float.).

In fact, Hungarian notation only came around as a misunderstanding. The inventor had intended for it to be used to describe the "conceptual" type of a variable (is it a coordinate, an index, a counter, a window?)

And the people who read his description assumed that by "type" he meant the actual programming language type (int, float, zero-terminated string, char pointer)

That was never the intention, and it is a horrible idea. It duplicates information that the IDE can better provide, and which isn't all that relevant in the first place, as it encourages you to program at the lowest possible level of abstraction.

So why? Am I the only person that has m_strExePath или m_iNumber в моем C # код?

Нет. К сожалению нет. Скажите, что было бы exePath , если бы не было строкой? Почему я, читатель вашего кода, должен знать, что это строка? Разве не достаточно знать, что это путь к исполняемому файлу? m_iNumber просто плохо назван. какой номер это? Для чего это? Вы только что дважды сказали мне, что это число, но я до сих пор не знаю, что означает число.

Нет, вы не единственный, кто это делает. Просто общепризнанно, что венгерская нотация - не лучший способ называть вещи в C # (IDE много решает проблемы, которые венгерская нотация пыталась решить).

You're not the only person, but I'd say it's relatively uncommon. Personally I'm not a fan of Hungarian notation, at least not in the simple sense that just restates the type information which is already present in the declaration. (Fans of "true" Hungarian notation will explain the difference - it's never bothered me that much, but I can see their point. If you use a common prefix for, say, units of length vs units of weight, you won't accidentally assign a length variable with a weight value, even though both may be integers.)

However, for private members you can pretty much do what you want - agree with your team what the naming convention should be. The important point is that if you want your API to fit in with the rest of .NET, don't use Hungarian notation in your public members (including parameters).

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

lblTitle = Label
txtTitle = TextBox
ddlTitle = DropDownList

Мне легче читать и анализировать. В противном случае венгерская нотация не подходит из-за достижений в IDE, в частности в Visual Studio.

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

В языке, подобном C #, где не существует многих ограничений на длину имени переменной, которые когда-то были в языках, подобных C и C ++, и там, где IDE предоставляет отличную поддержку для определения типа переменной, венгерская нотация избыточна.

Код должен быть понятен, поэтому имена, такие как m_szName, могут быть заменены this.name. И m_lblName может быть nameLabel и т. Д. Важно быть последовательным и создавать код, который легко читать и обслуживать - это цель любого соглашения об именовании, поэтому вы всегда должны решать, какое соглашение вы используете, основываясь на этом. Мне кажется, что венгерская нотация не самая читаемая и не самая удобная для обслуживания, потому что она может быть слишком краткой, требует определенного объема знаний о том, что означают префиксы, и не является частью языка и, следовательно, трудно применить и трудно определить, когда имя больше не соответствует базовому типу.

Вместо этого я предпочитаю заменять Apps Hungarian (префиксы, такие как m_), ссылаясь на this для членов, ссылаясь на имя класса для статические переменные и без префикса для локальных переменных. И вместо System Hungarian (включая тип переменной в имени переменной) я предпочитаю описывать, для чего предназначена переменная, например nameLabel, nameTextBox, count и databaseReference.

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

Я нашел очень мало пользы для указателей в C #, особенно когда нет неуправляемых / pinvoke вызовов. Кроме того, нет возможности использовать void *, поэтому венгру не нужно его описывать.

Единственный остаток от венгерского языка, который я (и большинство других в C # land) использую, состоит в том, чтобы предшествовать частным полям с _ , как в _customers ;

Единственный остаток от венгерского языка, который я (и большинство других в C # land) использую, - это предшествовать частным полям с _ , как в _customers ;

Единственный остаток от венгерского языка, который я (и большинство других в C # land) использую, состоит в том, чтобы предшествовать частным полям с _ , как в _customers ;

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

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

Что касается веских причин не использовать его, ну, есть немало. Во-первых, в C # и, в этом отношении, в C ++ и во многих других областях, вы часто создаете свои собственные типы, так что же будет венгерским для типа «MyAccountObject»? Даже если вы можете выбрать разумные венгерские нотации, это все равно делает реальное имя переменной немного труднее для чтения, потому что вы должны пропустить "LPZCSTR" (или что-то еще) в начале. Однако более важна стоимость обслуживания, что если вы начнете со Списка и перейдете на другой тип коллекции (то, что я, похоже, сейчас много делаю)? Затем вам нужно переименовать все ваши переменные, которые используют этот тип, и все это без реальной выгоды. Если вы только что использовали приличное имя, для начала вам не пришлось бы об этом беспокоиться.

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

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

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

Я не забочусь, я всегда использую комбинацию венгерского языка и Паскаля/Camel-регистра.

Не для типов данных, а для средств управления. Поскольку txtName довольно очевиден. Некоторые люди назовут это NameTextBox, который является слишком длинным. lblAge, txtName, rdoTrue, cboCities, lstAccountInfo. Хороший и быстрый и компактный Для переменных, это - Pascal-регистр для обычных переменных и свойств. "firstName = txtFName. Текст" (серьезно, если Вы не можете посмотреть на это и понять, что это - текстовое поле, sheez). Тогда я буду использовать Camel-регистр для методов

public void PrintNames (string fName, string lName)
{
    lblFullName.Text=fName + " " + lName;
}

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