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

Question

До использования C # C ++ был моим основным языком программирования. И венгерская нотация глубоко в моем сердце.

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

private string m_strExePath;

Пока я не прочитал что-то от ТАК, которое говорило:

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

Так почему? Я единственный человек, который имеет m_strExePath или m_iNumber в моем коде C #?

Answer 1

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

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

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

Answer 2

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

Answer 3

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

Answer 4

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

С тех пор прошло много лет ...

Вот что говорится в последней документации по ядру Linux (жирный шрифт):

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

Обратите внимание, что существует два типа венгерской нотации:

• Системы Венгерская нотация : Префикс кодирует физический тип данных.

• Приложения Венгерская нотация : Префикс кодирует логический тип данных.

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

Answer 5

Речь идет об эффективности. Сколько времени было потрачено на присвоение неверного значения переменной. Наличие точных переменных объявлений о повышении эффективности. Это о читабельности. Это о следовании существующим закономерностям. Если вы хотите творчества, занимайтесь дизайном пользовательского интерфейса, архитектурой системы. Если ваше программирование, оно должно быть разработано так, чтобы облегчить вашу работу членам команды: не вашей Повышение эффективности на 2% - это дополнительная неделя каждый год. Это 40 часов. Повышение производительности человека достигается за счет повышения эффективности.

Answer 6

Это зависит.

Достаточно ли , чтобы добавить описание типа данных в имя переменной / объекта в ваш метод / класс?

Системная нотация на венгерском языке> Apps Венгерская нотация

Если вы разрабатываете на процедурном языке (например, C), который имеет много глобальных переменных или / и более низкий API, который имеет дело с точными типами и размерами данных (например, C <stdint.h>, где для обозначения используются более 40 различных типов данных) описать int), система венгерской нотации более полезна.

Обратите внимание, однако, что многие современные программисты считают, что добавление информации о типе в имя переменной широко распространено, поскольку многие современные IDE имеют очень удобные инструменты (например, Outline Eclipse, Symbol Navigator Xcode , Visual AssistX для Visual Studio и т. Д.). Системная венгерская нотация широко использовалась в более ранние века в программировании (например, FORTRAN, C99), когда информация о типе не была легко доступна в качестве инструмента IDE.

Системная нотация на венгерском языке

Если вы работаете с классом или методом более высокого уровня (например, определяемым пользователем классом / методом драйвера для вашего приложения C #), отметка простого типа данных может быть недостаточной для описания переменной / объекта. Поэтому в этом случае мы используем Apps Венгерскую нотацию.

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

private string mPathExe;
private string msgNotFound;

Answer 7

В какой-то момент у вас может появиться свойство

public string ExecutablePath { ... }

. В таком случае ваш вопрос может быть спорным, поскольку вы можете использовать авто-свойства C # 3.0

public string ExecutablePath { get; set; }

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

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

Answer 8

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

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

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