Нужны ли переменные префиксы ( "венгерская нотация" )?

Ответ 1

Необходимы ли переменные префиксы (венгерские)?

НЕТ!

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

Не используйте венгерскую нотацию.

Ответ 2

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

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

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

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

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

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

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

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

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

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

Ответ 4

Неа. Мы когда-либо должны были?

Ответ 5

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

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

Ответ 6

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

Ответ 7

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

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

Ответ 8

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

В настоящих Руководящих принципах Microsoft здесь.

Ответ 9

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

Здесь выдержка

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

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

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

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

Ответ 10

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

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

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

Ответ 11

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

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

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

Ответ 12

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

Ответ 13

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

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

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

Ответ 14

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

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

Ответ 15

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

Стив

Ответ 16

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

Ответ 17

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

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

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

Ответ 18

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

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

Ответ 19

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

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

Ответ 20

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

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

Ответ 21

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

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

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

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

Ответ 22

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

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

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

Отношения Эмиль

Ответ 23

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

public class Test
{
    private int _id;
}

Ответ 24

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

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

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

Ответ 25

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

Ответ 26

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

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

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

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

Ответ 27

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

Лично я нахожу, что это помогает.

Ответ 28

Короткий ответ НЕТ. Но...

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

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

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

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

Ответ 29

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

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