Я должен использовать Венгерскую запись при кодировании приложений WinAPI? [закрытый]

6
задан szx 20 July 2010 в 19:18
поделиться

5 ответов

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

также посмотрите эту статью: http://www.joelonsoftware.com/articles/Wrong.html

7
ответ дан 8 December 2019 в 18:30
поделиться

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

Однако сейчас это уже не так (и не так уже несколько десятилетий). В настоящее время даже компиляторы языка C действительно выполняют реальную проверку типов, а компиляторы почти всех других языков делают гораздо больше. Даже компилятор, который был устаревшим и посредственным десять лет назад, будет выполнять эту работу гораздо эффективнее, чем кодирование информации о типе в имени переменной дает вам надежду сделать это самостоятельно. Если уж на то пошло, даже ассемблеры сейчас делают достаточную проверку типов, чтобы предотвратить многие или почти все виды проблем, для решения которых предназначалась HN.

Хуже того, люди, использующие HN, часто полагают, что он сделает что-то полезное, и из-за этого игнорируют то, что компилятор может сделать. В результате они получают код, который значительно хуже (хрупкий, граничащий с ошибками), чем если бы они вообще не использовали компилятор. Огромное количество кода Microsoft демонстрирует подобную проблему (например, DWORD используется для всевозможных несовместимых целей, а люди считают, что присвоение одного другому имеет смысл, потому что у них обоих есть префикс "dw").

Что еще хуже, код, использующий HN, гораздо менее удобен для сопровождения, чем код без него. В качестве яркого примера посмотрите, сколько текущего кода все еще использует префикс "lpsz", хотя концепция "длинных" и "коротких" указателей последний раз была актуальна в Windows 3.1, почти 20 лет назад. Теоретически, все это должно было быть исправлено во время перехода на 32-битный код ~15 лет назад - но это потребовало бы огромного количества работы по редактированию кода без какой-либо пользы (поскольку HN все равно ничего не стоит, наличие "правильного" psz не будет лучше, чем "неправильный" lpsz).

5
ответ дан 8 December 2019 в 18:30
поделиться

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

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

Сказав это, не следует идиотскому соглашению о префиксе целочисленных переменных с помощью i или строк с помощью lpst ; чем раньше эта глупость умрет, тем лучше. HN был предназначен для передачи более абстрактной семантики; цель состояла в том, чтобы определить, какие объекты были безопасными или подходящими для использования для конкретной операции (статья Joel on Software, на которую ссылается ruslik, является довольно хорошим аргументом в пользу этого).IOW, имена переменных должны обозначать использование , а не тип , и HN был попыткой кодифицировать использование.

Лично я предпочитаю использовать осмысленные имена на английском (или на родном языке по вашему выбору), которые прямо говорят вам, с чем вы имеете дело, а не с какой-то искусственной схемой кодирования; исходя из приведенного выше примера Джоэла, я бы просто использовал такие имена, как rawName и encodedName , а не usName и sName . Он передает почти ту же семантическую информацию, и он также лучше читается (во всяком случае, IMO).

1
ответ дан 8 December 2019 в 18:30
поделиться
В

Joel on Software есть фантастическая статья, объясняющая, почему (a) вы ДОЛЖНЫ ненавидеть венгерский язык, который вы видите в windows Apps, и (b) почему вы должны серьезно рассмотреть возможность его использования.

Если вы разрабатываете на C, то нотация под названием Apps Hungarian незаменима и поможет вам писать правильный код. Если вы разрабатываете на безопасном по типам ОО-языке, таком как C++, вам НЕ следует использовать венгерский язык, поскольку он просто не нужен.

1
ответ дан 8 December 2019 в 18:30
поделиться

НЕТ !!!

-1
ответ дан 8 December 2019 в 18:30
поделиться
Другие вопросы по тегам:

Похожие вопросы: