Почему я не должен использовать “Венгерскую запись”?
NullPointerException s - исключения, возникающие при попытке использовать ссылку, которая указывает на отсутствие местоположения в памяти (null), как если бы она ссылалась на объект. Вызов метода по нулевой ссылке или попытка получить доступ к полю нулевой ссылки вызовет функцию NullPointerException. Они наиболее распространены, но другие способы перечислены на странице NullPointerException javadoc.
Вероятно, самый быстрый пример кода, который я мог бы придумать для иллюстрации NullPointerException, be:
public class Example {
public static void main(String[] args) {
Object obj = null;
obj.hashCode();
}
}
В первой строке внутри main я явно устанавливаю ссылку Object obj равной null. Это означает, что у меня есть ссылка, но она не указывает на какой-либо объект. После этого я пытаюсь обработать ссылку так, как если бы она указывала на объект, вызывая метод на нем. Это приводит к NullPointerException, потому что нет кода для выполнения в местоположении, на которое указывает ссылка.
(Это техничность, но я думаю, что она упоминает: ссылка, которая указывает на null, равна 't то же, что и указатель C, указывающий на недопустимую ячейку памяти. Нулевой указатель буквально не указывает на в любом месте , который отличается от указаний на местоположение, которое оказывается недопустимым.)
34 ответа
Большинство людей использует Венгерскую запись неправильным способом и получает неправильные результаты.
Read эта превосходная статья Joel Spolsky: Взгляд Неверного кода Создания Неправильно .
Короче говоря, Венгерская запись, где Вы снабжаете префиксом свои имена переменной их type (строка) (Системный венгр) плоха, потому что это бесполезно.
Венгерская запись, как было предназначено ее автором, где Вы снабжаете префиксом имя переменной ее kind (использование примера Joel: безопасная строка или небезопасная строка), так называемый венгерский язык Приложений имеет свое использование и все еще ценен.
Несколько причин:
- Любой современный IDE даст Вам тип переменной путем простого парения мыши над переменной.
- Большинство имен типов является путем долго (думайте HttpClientRequestProvider) обоснованно использоваться в качестве префикса.
- информация о типе не несет право информация, это просто перефразирует объявление переменной, вместо того, чтобы обрисовать в общих чертах цель из переменной (думайте myInteger по сравнению с размер страницы ).
В словах ведущего устройства:
http://www.joelonsoftware.com/articles/Wrong.html
интересное чтение, как обычно.
Извлечения:
"Кто-то, где-нибудь, прочитал газету Simonyi’s, где он использовал слово “type, ” и думал, что имел в виду тип, как класс, как в системе типов, как тип, проверяющий, что компилятор делает. Он не сделал. Он объяснил очень тщательно точно, что он подразумевал под словом “type, ”, но это справка didn’t. Ущерб был нанесен".
, "Но there’s все еще огромная сумма значения венгру Приложений, на котором это увеличивает словосочетание в коде, который делает код легче читать, пишут, отлаживают и поддерживают, и, самое главное, это заставляет неверный код выглядеть неправильным".
Удостоверяются, что у Вас есть некоторое время прежде, чем считать Joel На программном обеспечении. :)
Я не думаю, что все бешено против него. На языках без статических типов это довольно полезно. Я определенно предпочитаю его, когда это используется для предоставления информации, которая уже не находится в типе. Как в C, символ * szName говорит, что переменная будет относиться к завершенной строке пустого указателя - это не неявно в символе* - конечно, определение типа также помогло бы.
у Joel была большая статья об использовании венгерского языка, чтобы сказать, был ли переменной закодированный HTML или нет:
http://www.joelonsoftware.com/articles/Wrong.html
Так или иначе, я склонен не любить венгерский язык, когда он используется для передачи информации, я уже знаю.
Конечно, когда 99% программистов договариваются о чем-то, существует что-то не так. Причина, которую они согласовывают здесь, состоит в том, потому что большинство из них никогда не использовало Венгерскую запись правильно.
Для подробного аргумента, я отсылаю Вас к сообщению в блоге, которое я сделал на предмете.
http://codingthriller.blogspot.com/2007/11/rediscovering-hungarian-notation.html
Венгерской записью злоупотребила, особенно Microsoft, ведя к префиксам дольше, чем имя переменной, и показав, что это довольно твердо, особенно при изменении типов (печально известный lparam/wparam, другого типа / размер в Win16, идентичном в Win32).
Таким образом, и из-за этого злоупотребления и его использования M$, это было подавлено как бесполезное.
На моей работе, мы кодируем в Java, но мужской рубашке основателя от мира MFC, так используйте подобный стиль кода (выровненные фигурные скобки, мне нравится это!, прописные буквы к именам методов, я привык к этому, префиксу как m_ для классификации участников (поля), s_ статическим участникам, и т.д.).
И они сказали, что все переменные должны иметь префикс, показывающий его тип (например, BufferedReader называют brData). Которые показавший как являющийся плохой идеей, поскольку типы могут измениться, но имена не следуют, или кодеры, не последовательны в использовании этих префиксов (я даже вижу aBuffer, theProxy, и т.д.!).
Лично, я выбрал для нескольких префиксов, которые я нахожу полезными, самое важное существо b к логическим переменным префикса, поскольку они - единственные, где я позволяю синтаксис как if (bVar) (нет смысла в автоброске некоторых значений к TRUE или FALSE). Когда я кодировал в C, я использовал префикс для переменных, выделенных с malloc как напоминание, это должно быть освобождено позже. И т.д.
Так, в основном, я не отклоняю эту нотацию в целом, но взял то, что кажется соответствующим моим потребностям.
И конечно, при содействии некоторому проекту (работа, открытый исходный код), я просто использую конвенции на месте!
Я начал кодировать в значительной степени о Венгерской записи времени, был изобретен и в первый раз, когда я был вынужден использовать ее на проекте, я ненавидел ее.
Через некоторое время я понял, что, когда это было сделано правильно, это действительно на самом деле помогало, и в эти дни я люблю его.
, Но как все хорошие вещи, это должно быть изучено и понято, и сделать это правильно занимает время.
Это - полезная конвенция для именования средств управления на форме (btnOK, txtLastName и т.д.), если список средств управления обнаруживается в расположенном в алфавитном порядке выпадающем списке в Вашем IDE.
Я склонен использовать Венгерскую запись с управлением сервером ASP.NET только , иначе мне также трудно разработать то, что средства управления что на форме.
Берут этот фрагмент кода:
<asp:Label ID="lblFirstName" runat="server" Text="First Name" />
<asp:TextBox ID="txtFirstName" runat="server" />
<asp:RequiredFieldValidator ID="rfvFirstName" runat="server" ... />
, Если кто-то может показать лучший способ наличия, что набор имен элементов управления без венгерского языка я испытал бы желание переместиться в него.
Я всегда думал, что префикс или два в правильном месте не причинил бы боль. Я думаю, могу ли я передать что-то полезное, как, "Эй это - интерфейс, не рассчитывайте на определенное поведение" тут же, как в IEnumerable, я, oughtta делают это. Комментарий может загромоздить вещи намного больше, чем просто один или два символьных символа.
Joel Spolsky записал хорошее сообщение в блоге об этом. http://www.joelonsoftware.com/articles/Wrong.html В основном это сводится к не созданию Вашего кода тяжелее для чтения, когда достойный IDE скажет о желании типа, который - переменная то, если Вы не можете помнить. Кроме того, если Вы делаете свой код, разделил достаточно, Вы не должны помнить то, чем переменная была объявлена как три страницы.
Я думаю, что это в широком масштабе загромождает исходный код.
Это также не получает Вас очень на языке со строгим контролем типов. Если Вы сделаете какую-либо форму дурачества несоответствия типов, то компилятор скажет Вам об этом.
Я всегда использую Венгерскую запись для всех своих проектов. Я нахожу это действительно полезным, когда я имею дело с 100 с различных имен идентификатора.
, Например, когда я вызываю функцию, требующую строки, я могу ввести' и поразить пространство управления, и мой IDE покажет мне точно имена переменной, снабженные префиксом'.
Другое преимущество, когда я снабжаю префиксом u для неподписанного и меня для ints со знаком, я сразу, видит, где я смешиваюсь подписанный и неподписанный потенциально опасными способами.
я не могу помнить количество раз, когда в огромных 75 000 кодовых баз строки, ошибки были вызваны (мной и другими также) из-за именования локальных переменных то же как существующие членские переменные того класса. С тех пор, я всегда участники префикса с 'm _'
вопрос вкуса и опыта. Не пробивайте его, пока Вы не попробовали его.
Не объем, более важный, чем тип в эти дни, например,
* l for local
* a for argument
* m for member
* g for global
* etc
С современными методами рефакторинга старого кода, поиска и замены символа, потому что Вы изменили его тип, утомительно, компилятор поймает изменения типа, но часто не будет ловить неправильное использование объема, разумная справка соглашений о присвоении имен здесь.
В Взгляд Неверного кода Создания Joel Spolsky Неправильно он объясняет, что, о чем все думают как Венгерская запись (который он называет Системным венгром) не то, что было, это было действительно предназначено, чтобы быть (что он называет венгром Приложений). Прокрутите вниз к Венгрия I’m заголовок для наблюдения этого обсуждения.
В основном, Системный венгр бесполезен. Это просто говорит Вам то же самое, которое Ваш компилятор и/или IDE скажут Вам.
венгр Приложений говорит Вам, что переменная, как предполагается, означает и может на самом деле быть полезной.
Прикрепление на загадочных символах в начале каждого имени переменной является ненужным и показывает, что имя переменной отдельно не является достаточно описательным. Большинство языков требует типа переменной в объявлении так или иначе, так, чтобы информация была уже доступна.
существует также ситуация, где во время обслуживания тип переменной должен измениться. Пример: если переменная, объявленная как "uint_16 u16foo", должна стать 64-разрядным неподписанным, одна из двух вещей произойдет:
- Вы пройдете и измените каждое имя переменной (удостоверяющийся не поливать из шланга любые несвязанные переменные с тем же именем), или
- Просто изменяют тип и не меняют имя, которое только вызовет беспорядок.
Вы забываете причину номер один включать эту информацию. Это не имеет никакого отношения к Вам, программисту. Это имеет все, чтобы сделать с человеком, приезжающим в будущем спустя 2 или 3 года после отъезда компании, которая должна считать тот материал.
Да, IDE быстро определит типы для Вас. Однако то, когда Вы прочитываете некоторые длинные пакеты кода 'бизнес-правил', хорошо не должным быть приостановиться на каждой переменной для обнаружения то, что вводит его. Когда я вижу вещи как strUserID, intProduct или guiProductID, он делает для очень более легкое время 'подъема'.
я соглашаюсь, что MS пошел слишком далеко с некоторыми их соглашениями о присвоении имен - я категоризирую это в "слишком большом количестве хорошей вещи" груда.
Соглашения о присвоении имен являются хорошими вещами, если Вы придерживаетесь их. Я прошел достаточно старого кода, который, постоянно имел меня возвращаясь для рассмотрения определений для такого количества так же названных переменных, что я продвигаю "преобразование регистра верблюда" (как это назвали в предыдущем задании). Прямо сейчас я нахожусь на задании, которое имеет много тысяч строк полностью непрокомментированного классического кода ASP с VBScript, и это - кошмар, пытающийся понимать вещи.
Нет никакой причины, почему Вы не должны делать корректный использование Венгерской записи. Это - непопулярность происходит из-за продолжительной обратной реакции против неправильное употребление из Венгерской записи, особенно в Windows APIs.
За плохие былые времена, перед чем-либо напоминающим IDE существовал для DOS (разногласия - Вы, не имел достаточного количества свободной памяти для выполнения компилятора в соответствии с Windows, таким образом, разработка была сделана в DOS), Вы не получили справки от парения Вашей мыши по имени переменной. (Принятие Вас имело мышь.), Что, действительно необходимо было иметь дело с, были функции обратного вызова события, в которых все было передано Вам или как 16-разрядный интервал (WORD) или как 32-разрядный интервал (ДЛИННОЕ СЛОВО). Затем необходимо было бросить их параметр к соответствующим типам для данного типа события. В действительности большая часть API была фактически без типов.
результат, API с названиями параметра как они:
LRESULT CALLBACK WindowProc(HWND hwnd,
UINT uMsg,
WPARAM wParam,
LPARAM lParam);
Примечание, что имена wParam и lParam, хотя довольно ужасный, не действительно так хуже, чем именование их param1 и param2.
Для усугубления положения Окно 3.0/3.1 имело два типа указателей, рядом и далеко. Так, например, возвращаемое значение из памяти функция управления, LocalLock был PVOID, но возвращаемое значение от GlobalLock было LPVOID (с 'L' долгое время). Та ужасная нотация затем была расширена так, чтобы строка long pointer была снабжена префиксом альбом , для различения ее от строки, которая просто была malloc'd.
не удивительно, что была обратная реакция против этого вида вещи.
Венгерская запись только имеет смысл на языках без пользовательских типов . В современном функциональном или языке OO, Вы закодировали бы информацию о "виде" значения в тип данных или класс, а не в имя переменной.
Несколько ссылок ответов статья Joels. Обратите внимание однако, что его пример находится в VBScript, который не поддерживал пользовательские классы (в течение долгого времени, по крайней мере). На языке с пользовательскими типами Вы решили бы ту же проблему путем создания HtmlEncodedString-типа и затем позволили бы Методу записи принять только это. На статически типизированном языке компилятор поймает любые ошибки кодирования, в с динамическим контролем типов Вы получили бы исключение на этапе выполнения - но в любом случае Вы защищены от записи незакодированных строк. Венгерские записи просто превращают программиста в человеческое средство проверки типа, с вид задания, которое обычно лучше обрабатывается программным обеспечением.
Joel различает "системного венгра" и "венгра приложений", где "системный венгр" кодирует встроенные типы как интервал, плавание и так далее, и "венгр приложений" кодируют "виды", который является высокоуровневой метаинформацией о переменной вне типа машины В OO или современном функциональном языке, можно создать пользовательские типы, таким образом, нет никакого различия между типом и "видом" в этом смысле - и не может быть представлено системой типов - и венгр "приложений", так же избыточно как "системный" венгр.
Так для ответа на вопрос: Системный венгр только был бы полезен на небезопасном, языке со слабым контролем типов, где, например, присвоение значения плавающего к международной переменной разрушит систему. Венгерская запись была конкретно изобретена в шестидесятых для использования в BCPL , довольно низкоуровневый язык, который не сделал никакой проверки типа вообще. Я не думаю, что любой язык во всеобщем употреблении сегодня имеет эту проблему, но нотация жила на как своего рода , грузовой культовый венгр Приложений программирования .
будет иметь смысл, если Вы будете работать с языком без определяемых пользователем типов, как VBScript прежней версии или ранние версии VB. Возможно, также ранние версии Perl и PHP. Снова, использование его в современном languge является чистым грузовым культом.
На любом другом языке, венгерский язык просто ужасен, избыточен и хрупок. Это повторяет информацию, уже известную от системы типов, и Вы не должны повторять себя . Используйте описательное имя для переменной, которая описывает намерение этого определенного экземпляра типа. Используйте систему типов для кодирования инвариантов и meta информации о "видах" или "классах" переменных - т.е. типы.
общая точка статьи Joels - чтобы иметь взгляд неверного кода неправильно - является очень хорошим принципом. Однако еще лучшая защита от ошибок к - когда вообще возможный - имеют неверный код, который будет обнаружен автоматически компилятором.
Венгерская запись может быть полезной на языках без проверки типа времени компиляции, поскольку она позволила бы разработчику быстро напоминать себе о том, как конкретная переменная используется. Это ничего не делает для производительности или поведения. Это, как предполагается, улучшает удобочитаемость кода и является главным образом вопросом вкус и стиль кодирования. По этой самой причине это критикуется со стороны многих разработчиков - не у всех есть то же проводное соединение в мозгу.
Для языков проверки типа времени компиляции это главным образом бесполезно - прокрутка, несколько строк должны показать объявление и таким образом ввести. Если Вы, которых глобальные переменные или Ваш блок кода охватывают для намного больше чем одного экрана, у Вас есть серьезный дизайн и проблемы возможности многократного использования. Таким образом одно из критических замечаний - то, что Венгерская запись позволяет разработчикам иметь плохой дизайн и легко выходить сухим из воды. Это - вероятно, одна из причин ненависти.
, С другой стороны, могут быть случаи, где даже языки проверки типа времени компиляции извлекли бы выгоду из Венгерской записи - пустой указатели или ДЕСКРИПТОР в win32 API. Они запутывают фактический тип данных, и могла бы быть заслуга для использования Венгерской записи там. Все же, если можно знать тип данных во время изготовления, почему не использовать соответствующий тип данных.
В целом, нет никаких трудных причин не использовать Венгерскую запись. Это - вопрос, любит, политики и стиль кодирования.
IDE должен передать ту полезную информацию. Венгерский язык, возможно, сделал некоторый вид (не много, но некоторый вид) смысла, когда IDE был намного менее усовершенствован.
Как Python программист, Венгерская запись разваливается довольно быстро. В Python я не забочусь, ли что-то строка - я забочусь, может ли он действие как [1 111] строка (т.е. если он имеет ___str___() метод, который возвращает строку).
, Например, скажем, у нас есть нечто как целое число, 12
foo = 12
, Венгерская запись говорит нам, что мы должны назвать это iFoo или чем-то, чтобы обозначить, что это - целое число, так, чтобы позже, мы знали, каково это. Кроме Python, который не работает, или скорее это не имеет смысла. В Python я решаю то, что вводит, я хочу, когда я использую его. Я хочу строку? хорошо, если я делаю что-то вроде этого:
print "The current value of foo is %s" % foo
Примечание %s - строка. Нечто не является строкой, но %, оператор будет называть foo.___str___() и использовать результат (предполагающий, что это существует). foo все еще целое число, но мы рассматриваем его как строку, если мы хотим строку. Если мы хотим плавание, то мы рассматриваем его как плавание. На динамически типизированных языках как Python Венгерская запись бессмысленна, потому что не имеет значения, что вводит что-то, пока Вы не используете его, и если Вам нужен определенный тип, затем просто удостоверьтесь, что бросили его к тому типу (например, float(foo)) при использовании его.
Примечание, что динамические языки как PHP не обладают этим преимуществом - PHP, пытается сделать 'правильную вещь' в фоновом режиме на основе неясного подшипника, который почти никто не запомнил, который часто неожиданно приводит к катастрофической путанице. В этом случае своего рода механизм именования, как $files_count или $file_name, может быть удобным.
, По моему мнению, Венгерская запись похожа на пиявки. Возможно, в прошлом они были полезны, или по крайней мере они казались полезными, но в наше время это - просто большой дополнительный ввод для не большое преимущество.
Это невероятно избыточно, и бесполезный большинство современных IDE, где они делают хорошее задание создания очевидного типа.
Плюс - мне - это является просто раздражающим для наблюдения инти, strUserName, и т.д. :)
Im мой опыт, это плохо потому что:
1 - затем Вы взламываете весь код, если необходимо изменить тип переменной (т.е. если необходимо расширить целое число на 32 бита до целого числа на 64 бита);
2 - это - бесполезная информация, как тип или уже в объявлении, или Вы используете динамический язык, где фактический тип не должен быть настолько важным во-первых.
, Кроме того, с языком, принимающим универсальное программирование (т.е. функции, где тип некоторых переменных не, определяют, когда Вы пишете функцию), или с системой динамического контроля типов (т.е. когда тип даже не, определяют во время компиляции), как Вы назвали бы свои переменные? И наиболее современные языки поддерживают один или другой, даже если в ограниченной форме.
vUsing adjHungarian nnotation vmakes nreading ncode adjdifficult.
Joel неправ, и здесь почему.
, Что информация "о приложении" он говорит приблизительно должны быть закодированы в системе типов . Вы не должны зависеть от зеркального отражения имен переменной, чтобы удостовериться, что Вы не передаете небезопасные данные функциям, требующим безопасных данных. Необходимо сделать это ошибкой типа, так, чтобы это было невозможно , чтобы сделать так. Любые небезопасные данные должны иметь тип, который отмечен небезопасный, так, чтобы они просто не могли быть переданы безопасной функции. Преобразовать от небезопасного до сейфа должно потребовать обработки с некоторым санировать функцию.
Большим количеством вещей, о которых Joel говорит как "виды", не являются виды; они - на самом деле, типы.
то, В чем большинство языков испытывает недостаток, однако, является системой типов, это достаточно выразительно для осуществления подобных различий. Например, если бы C имел своего рода "сильное определение типа" (где имя определения типа начало все операции базового типа, но не было конвертируемо к нему), затем, много этих проблем ушло бы. Например, если Вы могли бы сказать, strong typedef std::string unsafe_string; для представления нового типа unsafe_string, который не мог бы быть преобразован в станд.:: строка (и так мог участвовать в разрешении перегрузки и т.д. и т.д.) затем нам не будут нужны глупые префиксы.
Так, центральное заявление, что венгерский язык для вещей, которые не являются типами, является неправильным. Это используется для получения информации о типе. Более богатая информация о типе, чем традиционный C вводит информацию, конечно; это - информация о типе, которая кодирует некоторую семантическую деталь для указания на цель объектов. Но это - все еще информация о типе, и надлежащее решение состояло в том, чтобы всегда кодировать его в систему типов. Кодирование его в систему типов является бесспорно лучшим способом получить надлежащую проверку и осуществление правил. Имена переменных просто не сокращают горчицу.
, Другими словами, цель не должна быть, "заставляют неверный код выглядеть неправильным разработчику". Это должно быть, "заставляют неверный код выглядеть неправильным к компилятору ".
, Если я чувствую, что полезная информация передается, почему я не должен помещать ее тут же, где это доступно?
Затем, кто заботится о том, что кто-либо еще думает? При нахождении этого полезным то используйте нотацию.
Я думаю все это о , эстетический аспект сверхраздут . Если бы это было самой важной вещью, то мы не назвали бы себя разработчики , но графический разработчики .
Одна важная часть, я думаю, то, что Вы описываете, какова Ваша роль объектов, не, каково это. Вы не называете себя HumanDustman, becuase в другом контексте, Вы не самое главное были бы человеком.
Для целей рефакторинга это действительно важно также:
public string stringUniqueKey = "ABC-12345";
, Что, если бы Вы решаете использовать GUID вместо строки, Ваше имя переменной выглядело бы глупым после рефакторинга всего кода обращения.
Или:
public int intAge = 20;
Изменение этого к плаванию, у Вас была бы та же проблема. И так далее.
- Они - огромное бельмо на глазу
- , Ваш IDE должен смочь сказать Вам всем, которые необходимо знать о типе
- переменной Хорошие имена (какой HN мешает), должен передать Вам все остальное, что необходимо знать о переменной.
Венгерский язык плох, потому что он устраняет драгоценные символы из имен переменной в обмен на какой, некоторая информация о типе?
, В первую очередь, на языке со строгим контролем типов, компилятор предупредит Вас, если Вы сделаете кого-либо действительно глупого.
112-секундный, если Вы верите в хороший построенный из модулей код и не делаете слишком большой работы ни в какой 1 функции, Вы - переменные, вероятен объявленный чуть выше кода, в котором они используются так или иначе (таким образом, у Вас есть тип тут же).
В-третьих, при добавлении префикса каждого указателя p и каждого класса с C, действительно завинчивание способность хорошего современного IDE сделать intellisense (Вы знаете, что функция, где это предполагает, поскольку Вы вводите, что имя класса Ваш ввод и как только это получает его правильный, что Вы совершаете нападки, может войти, и это завершает его для Вас? хорошо при добавлении префикса каждого класса C у Вас всегда есть по крайней мере 1 дополнительная буква для ввода)...