Переменные префиксы (“Венгерская запись”) больше действительно необходимы? [закрытый]

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

НЕТ!

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

не используют Венгерскую запись.

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

Однако я НАСТАИВАЮ, чтобы Вы действительно снабдили префиксом средства управления их тип, такие как txtName.

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

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

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

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

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

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

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

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

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

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

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

public class Test
{
    private int _id;
}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

я иду с Microsoft и использую их Стили Капитализации для всех соглашений о присвоении имен. Весь раздел "Design Guidelines for Class Library Developers", которого та ссылка является частью, является чистым золотом, по-моему.

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

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

Вот является выборкой

"В версии Simonyi’s Венгерской записи, каждая переменная была снабжена префиксом тег нижнего регистра, который указал на вид вещи, которую содержала переменная.

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

I’m с помощью вида слова нарочно, там, потому что Simonyi по ошибке использовал словоформу в его статье и поколения программистов, неправильно понял то, что он имел в виду".

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

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

текущая Microsoft Guidelines здесь .

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

Steve

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

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

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

Нет. Мы когда-нибудь потребность к?

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

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

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

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

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

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

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

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

РЕДАКТИРОВАНИЕ: Я действительно читал инструкции Microsoft. Однако я полагаю, что стилям кодирования позволяют развиться и/или быть "изогнутыми", в соответствующих случаях. Как я упомянул выше, я нашел префикс подчеркивания использования полезным методом проб и ошибок и конечно лучше, чем использование this.whatever везде в коде.

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

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

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

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

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

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

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

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

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

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

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 вполне способны предоставить вам всю информацию, которую вы должны знать о каждом идентификаторе. Достаточно честно.

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

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