Люди используют венгерские Соглашения о присвоении имен в реальном мире? [закрытый]
Вам нужно указать поле, которое вы хотите вернуть, используя проекцию.
data = db.author.find_one({'email' : email, 'password' : password}, {'_id': 1})
20 ответов
Рассмотрение, что большинство людей, которые используют Венгерская запись , следует за недооцененной версией его, я сказал бы, что это довольно бессмысленно.
, Если Вы хотите использовать исходное определение его, оно могло бы иметь больше смысла, но кроме которого это - главным образом синтаксический сахар.
, Если Вы читаете статья Wikipedia о предмете, Вы найдете две конфликтующих нотации, Системная Венгерская запись и Венгерская запись Приложений .
оригинал, хороший, определение, эти Венгерская запись Приложений , но большинство людей использует эти Системная Венгерская запись .
Как пример этих двух, рассмотрите переменные добавления префикса с l для длины, для области и v для объема.
С такой нотацией, следующее выражение имеет смысл:
int vBox = aBottom * lVerticalSide;
, но это не делает:
int aBottom = lSide1;
, Если Вы смешиваете префиксы, их нужно считать частью уравнения и объемом = область *, длина хорошо для поля, но копирование значения длины в переменную области должно повысить некоторые красные флаги.
, К сожалению, другая нотация менее полезна, где люди снабжают префиксом имена переменной тип значения, как это:
int iLength;
int iVolume;
int iArea;
некоторые люди используют n для числа или меня для целого числа, f для плавания, s для строки и т.д.
, исходный префикс был предназначен, чтобы использоваться для определения проблем в уравнениях, но так или иначе опустился до создания кода, немного легче читать, так как Вы не должны искать объявление переменной. С сегодняшними умными редакторами, где можно просто нависнуть над любой переменной для нахождения полного типа, и не только сокращения для него, этот тип венгерской записи потерял большое свое значение.
, Но, необходимо решиться. Все, что я могу сказать, - то, что я не использую также.
<час>Редактирование Только для добавления короткого уведомления, в то время как я не использую Венгерская запись , я действительно использую префикс, и это - подчеркивание. Я снабжаю префиксом все частные поля классов с _ и иначе записываю их имена, поскольку я был бы свойство, titlecase с первым верхним регистром буквы.
Я использую базирующийся тип (Системы HN) для компонентов (например, editFirstName, lblStatus и т.д.), поскольку это заставляет автоматическое заполнение работать лучше.
я иногда использую Приложение HN для переменных, где информацией о типе является isufficient. Т.е. fpX указывает на фиксированную резкую переменную (международный тип, но не может быть смешан и соответствовать интервалу), rawInput для пользовательских строк, которые не были проверены и т.д.
Исходная форма (Правильная Венгерская запись:)), где тип средств префикса (т.е. длина, количество) значения, сохраненного переменной, в порядке, но не необходим во всем типе приложений.
популярная форма (Неправильная Венгерская запись), где тип средств префикса (Строка, интервал) бесполезен на большинстве современных языков программирования.
Особенно с бессмысленными именами как Стра. Я не могу понять нас, люди используют бессмысленные имена с длинными префиксами, который ничего не дает.
Это зависит от Вашего языка и среды. Как правило, я не использовал бы его, если из-за среды разработки, в которой Вы находитесь, не сложно находить тип переменной.
существует также два различных типов Венгерской записи. См. статью Joel. Я не могу найти его (его имена точно не делают их легкими найти), у кого-либо есть ссылка на ту, которую я имею в виду?
Редактирование: Клин имеет статью, которую я имею в виду в его сообщении.
Я работал на IBM в течение прошлых 6 месяцев, и я не видел, она где угодно (благодарите бога, потому что я ненавижу ее.) Я вижу или Camel-регистр или c_style.
thisMethodIsPrettyCool()
this_method_is_pretty_cool()
При использовании динамически типизированного языка я иногда использую венгра Приложений. Для статически типизированных языков я не делаю. Посмотрите мое объяснение в другом потоке .
исходный префикс был предназначен, чтобы использоваться для определения проблем в уравнениях, но так или иначе опустился до создания кода, немного легче читать, так как Вы не должны искать объявление переменной. С сегодняшними умными редакторами, где можно просто нависнуть над любой переменной для нахождения полного типа, и не только сокращения для него, этот тип венгерской записи потерял большое свое значение.
я повреждаю привычку немного, но снабжаю префиксом тип, может быть полезным в JavaScript, который не имеет сильного переменного ввода.
Я использую венгерское Именование для кнопок Мне нравится элементов UI, текстовых полей и маркировок. Основное преимущество группирует в Visual Studio Всплывающее окно Intellisense. Если я хочу получить доступ к своим маркировкам, я просто начинаю вводить lbl...., и Visual Studio предложит все мои маркировки, приятно группировался.
Однако после выполнения все большего количества Silverlight и материала WPF, усиливая привязку данных, я даже больше не называю все свои средства управления, так как я не должен ссылаться на них от кода - позади (так как действительно нет никакого codebehind больше;)
Когда я вижу венгерское обсуждение, я рад видеть, что люди думают трудно о том, как сделать их код более ясным, и как к ошибкам более видимый. Это точно, что мы должны все делать!
, Но не забывают, что у Вас есть некоторые мощные инструменты в Вашем распоряжении помимо именования.
Метод Извлечения , Если Ваши методы становятся такими длинными, который Ваши объявления переменной прокрутили от вершины экрана, считайте создание Ваших методов меньшим. (Если Вы имеете слишком много методов, рассматриваете новый класс.)
Строгий контроль типов , Если Вы находите, что берете почтовый индекс с, сохраненная в целочисленной переменной, и присваиваете их размер обуви целочисленная переменная, рассмотрите создание класса для почтовых индексов и класса для размера обуви. Тогда Ваша ошибка будет поймана во время компиляции, вместо того, чтобы требовать тщательного контроля человеком. Когда я делаю это, я обычно нахожу набор почтового индекса - и определенная для размера обуви логика, которую я наперчил вокруг своего кода, который я могу тогда приблизиться к своим новым классам. Внезапно весь мой код становится более ясным, более простым, и защищенным от определенных классов ошибок. Ничего себе.
Для подведения: да, думайте трудно о том, как Вы используете имена в коде, чтобы выразить Ваши идеи ясно, но также и смотреть на другие мощные инструменты OO, к которым можно обратиться.
Что случилось смешивает стандарты.
то, Что является правильным, удостоверяется, что все делают то же самое.
int Box = iBottom * nVerticleSide
Не объем, более важный, чем тип в эти дни, например,
- л для локального
- для аргумента
- м для участника
- г для глобального
- и т.д.
С современными методами рефакторинга старого кода, поиска и замены символа, потому что Вы изменили его тип, утомителен, компилятор поймает изменения типа, но часто не будет ловить неправильное использование объема, разумная справка соглашений о присвоении имен здесь.
Я рассматриваю Венгерскую запись как способ обойти мощность нашей кратковременной памяти. По словам психологов, мы можем сохранить [приблизительно 115] 7 плюс-минус 2 блока из информации. Дополнительная информация, добавленная включением префикса, помогает нам путем предоставления больше подробной информации о значении идентификатора даже без другого контекста. Другими словами, мы можем предположить то, для чего переменная, не видя, как она используется или объявляется. Этого можно избежать путем применения oo методов такой как инкапсуляция и единственный принцип ответственности .
я не знаю, было ли это изучено опытным путем. Я выдвинул бы гипотезу, что усилие увеличивается существенно, когда мы пытаемся понять классы больше чем с девятью переменными экземпляра или методы больше чем с 9 локальными переменными.
Я думаю, что венгерская запись является интересной сноской вдоль 'пути' к большему количеству читаемого кода, и, если сделано правильно, предпочтительна для не сделанного он.
В высказывании этого, хотя, я покончил бы с ним, и вместо этого:
int vBox = aBottom * lVerticalSide;
запись это:
int boxVolume = bottomArea * verticalHeight;
Это - 2008. У нас больше нет починенных экранов ширины 80 символов!
кроме того, если Вы написали имена переменной, которые намного более длинны, чем это, необходимо смотреть на рефакторинг в объекты или функции так или иначе.
Извините, что добились вопроса, но интерфейсы добавления префикса с "I" квалифицируют как венгерская запись? Если это так, тогда да, много людей использует его в реальном мире. В противном случае проигнорируйте это.
Это бессмысленно (и отвлекающий), но находится в относительно интенсивном употреблении в моей компании, по крайней мере, для типов как ints, строки, булевские переменные, и удваивается.
Вещи как sValue, iCount, dAmount или fAmount, и bFlag везде.
Когда-то давно было серьезное основание для этого соглашения. Теперь, это - рак.
Я все еще использую Венгерскую запись когда дело доходит до элементов UI, где несколько элементов UI связаны с конкретным объектом/значением, например,
lblFirstName для объекта маркировки, txtFirstName для текстового поля. Я определенно не могу назвать их обоих "FirstName", даже если , что беспокойство/ответственность обоих объектов.
, Как другие приближаются к именованию элементы UI?
Венгерское Соглашение о присвоении имен может быть полезным, когда используется правильно, к сожалению, оно имеет тенденцию неправильно использоваться, как правило.
статья Read Joel Spolsky, Делающая Неправильный Взгляд Кода Неправильно для соответствующей перспективы и выравнивания.
По существу, основанная на типе Венгерская запись, где переменные снабжаются префиксом информацию о своем типе (например, ли объект является строкой, дескриптором, интервалом, и т.д.) главным образом бесполезна и обычно просто добавляет наверху с очень небольшим преимуществом. Это, к сожалению, Венгерская запись, с которой большинство людей знакомо. Однако намерение Венгерской записи, как предполагается состоит в том, чтобы добавить информацию о "виде" данных, которые содержит переменная. Это позволяет Вам видам раздела данных из других видов данных, которым нельзя позволить быть смешанными вместе кроме, возможно, посредством некоторого процесса преобразования. Например, основанные на пикселе координаты по сравнению с координатами в других единицах или небезопасный ввод данных пользователем по сравнению с данными из безопасных источников, и т.д.
Взгляд на него, этот путь при нахождении себя spelunking через код для обнаружения информации о переменной тогда Вы, вероятно, должен скорректировать Вашу схему именования для содержания той информации, это - сущность венгерского соглашения.
Примечание, что альтернатива Венгерской записи должна использовать больше классов для показа намерения переменного использования вместо того, чтобы полагаться на типы примитивов везде. Например, вместо того, чтобы иметь переменные префиксы для небезопасного ввода данных пользователем, у Вас могут быть класс обертки простой строки для небезопасного ввода данных пользователем и отдельный класс обертки для безопасных данных. Это имеет преимущество, на языках со строгим контролем типов, осуществления разделения компилятором (даже на меньшем количестве языков со строгим контролем типов, можно обычно добавлять собственный код растяжки), но добавляет весьма значительную сумму издержек.
Я не использую очень строгий смысл венгерской записи, но я действительно использую ее экономящий для некоторых общих пользовательских объектов помочь определить их, и также я склонен снабжать префиксом gui объекты управления тип управления, которое они. Например, labelFirstName, textFirstName, и buttonSubmit.
Венгерская нотация бессмысленна в типобезопасных языках. например, в старом коде Microsoft часто встречается префикс «lpsz», что означает «длинный указатель на строку с нулевым завершением». С начала 1700-х годов мы не использовали сегментированные архитектуры, в которых существуют короткие и длинные указатели, нормальное строковое представление в C ++ всегда заканчивается нулем, а компилятор является типобезопасным, поэтому не позволяет нам применять нестроковые операции к строка. Следовательно, никакая из этой информации не имеет реальной пользы для программиста - это просто больше набирает текст.
Однако я использую аналогичную идею: префиксы, которые разъясняют использование переменной. Основные из них:
- m = member
- c = const
- s = static
- v = volatile
- p = указатель (и pp = указатель на указатель и т. Д.)
- i = индекс или итератор
Их можно комбинировать, поэтому статическая переменная-член, которая является указателем, будет иметь вид «mspName».
Где они полезны?
- Если использование важно, рекомендуется постоянно напомните программисту, что переменная является (например) изменчивой или указательной
- Разыменование указателя, которое использовалось для моего понимания, пока я не использовал префикс p. Теперь действительно легко узнать, есть ли у вас объект (оранжевый) указатель на объект (pOrange) или указатель на указатель на объект (ppOrange). Чтобы разыменовать объект, просто поставьте перед ним звездочку для каждого p в его имени. Дело решено, ошибок больше нет!
- В конструкторах я обычно обнаруживаю, что имя параметра идентично имени переменной-члену (например, размер). Я предпочитаю использовать "mSize = size;" чем "size = theSize" или "this.size = size". Это также намного безопаснее: я не случайно использую «size = 1» (установка параметра), когда я хотел сказать «mSize = 1» (установка члена)
- В циклах все мои переменные итератора имеют значимые имена . Большинство программистов используют «i» или «index», а затем придумывают новые бессмысленные имена («j», «index2»), когда им нужен внутренний цикл. Я использую значимое имя с префиксом i (iHospital, iWard, iPatient), поэтому я всегда знаю, что повторяет итератор.
- В циклах вы можете смешивать несколько связанных переменных, используя одно и то же базовое имя с разными префиксами: Оранжевый оранжевый = pOrange [iOrange]; Это также означает, что вы не делаете ошибок индексирования массива (pApple [i] выглядит нормально, но запишите его как pApple [iOrange], и ошибка сразу станет очевидной).
- Многие программисты будут использовать мою систему, не зная об этом: добавив длинный суффикс, такой как "Index" или "Ptr" - IMHO нет никаких веских причин использовать более длинную форму, чем односимвольный, поэтому я использую "i" и "p". Меньше набора текста, более согласованный, легкий для чтения.
Это простая система, которая добавляет значимую и полезную информацию в код и исключает возможность многих простых, но распространенных ошибок программирования.
Это простая система, которая добавляет значимую и полезную информацию в код и исключает возможность многих простых, но распространенных ошибок программирования.
Это простая система, которая добавляет значимую и полезную информацию в код и исключает возможность многих простых, но распространенных ошибок программирования.
Будучи программистом PHP, где он очень слабо типизирован, я не собираюсь его использовать. Однако иногда я идентифицирую что-то как массив или как объект, в зависимости от размера системы и области действия переменной.