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

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

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

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

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

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

Are variable prefixes ( Hungarian ) really necessary anymore?

НЕТ!

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

Do not use Hungarian notation.

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

Другими словами, не используйте их больше.

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

Однако я НАСТОЯЩИМ, что вы делаете префиксные элементы управления с их типом, например txtName.

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

public class Test
{
    private int _id;
}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обновлено: Я прочитал рекомендации Microsoft. Однако я считаю, что стили кодирования могут развиваться и / или «изгибаться», где это уместно. Как я уже упоминал выше, я обнаружил, что использование префикса подчеркивания полезно методом проб и ошибок и, безусловно, лучше, чем использовать this.wesome везде в коде.

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

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

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

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

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

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

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

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

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

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

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

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

Стив

Если венгерский означает «префикс с аббревиатурой типа», такой как 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. Глубоко внутри функции вы всегда можете с первого взгляда определить, откуда взялась эта переменная. И обычно мы копируем переменную в другую, когда хотим изменить ее или изменить ее значение.

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

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

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

Вот отрывок

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я использую его только в своей базе данных (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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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