Соглашения по оформлению кода

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

 

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

 

_DEN_
-2

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

 

Венгерская нотация.

 

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

 

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

Если известно имя переменной без префиксов, подчас трудно восстановить её префиксы.
Кому трудно? Если только имбицилам.

Система автодокументации, если она не понимает системы префиксов, отсортирует алфавитный список по префиксу, что может отрицательно сказаться на качестве документации. Впрочем, имена функций обычно префиксами не снабжают.
Это недостаток системы автодокументации.

Запись нескольких префиксов из-за частого использования заглавных букв и знаков подчёркивания может стать «пляской на кнопке Shift».
Полный идиотизм.Демагогия чисто воды. Какой придурок это писал?

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

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

Great: такие высказывания стоит аргументировать.
(Заодно потер ругань)

 

Это всё вопрос привычки, удобства и прочее - тема бесконечная и тупиковая.
Согласен,

 

На самом деле это реально неудобно. Скажу как человек, который написал достаточное количество кода и с использованием сабжа и без и в итоге я теперь придерживаюсь следующего:
если из названия переменной явно ясно ее предназначение и тип (например char String[]), то я никакими префиксами ее не снабжаю.
Если неясно - снабжаю. Но имена переменных я часто даю информативные, поэтому от этой нотации я в конце концов практически отказался.

 

Osen

Какой кошмар, я этого не переживу.

 

Для остальных:

Главная проблема венгерки в том, что программист, воспользовавшийся венгеркой, добровольно соглашается на геморой: если вчера контролем типов занимался компилятор, то сегодня этим контролем вынужден заниматься сам программист. Если я напишу std::string m_pName; то никакой компилятор мне не скажет что у меня ошибка, по скольку это искусствено выдуманное правило. Теперь я сам вынужден следить за тем, чтобы информация о типе соответствовала действительности. Зачем мне оно надо, если еще вчера за этим прекрасно сделил компилятор. Ну и последнее - необходимость знания типа переменной для ее использования попросту говорит о неумении программировать.

 

Если и применять венгерскую нотацию, то не в простых алгоритмах. А то классно получится ddIndex dd 0 или там char* szLine;. Как-то мягко говоря избыточно. Сам я придерживаюсь просто понятных названий переменных, например row_index, или threadId. Вряд ли трезво мыслящий программист будет считать, что тот же row_index это массив или строка

to Great: вы меня опередили )

 

Xerx

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

 

_DEN_
Да да, именно. Венгерка - потенциальный разносчик программ с переменными вида dwSomething.
А вообще эта тема может перерасти в очередное противостояние, которое ни к чему не приведет и большинство останется при своем мнении, что Венгерка - "это не есть хорошо"

 

Osen
> Вообще стиль выбираем каждый сам.
местами, а при работе в команде (читай - на фирме) для того, чтобы не было разброда очень часто программерам навязывают стиль, выбранный кем-то из... членов... хм. руководства. и там не только венгерка... достаточно часто приходится сталкиваться, что запрещены короткие переменные вообще, даже общепринятые соглашения типа index -> idx -> i не катят. с другой стороны единство стиля все-таки лучше разброда, даже если это плохое единство ;(

_DEN_
> Главная проблема венгерки в том, что программист, воспользовавшийся
> венгеркой, добровольно соглашается на геморой:
> если вчера контролем типов занимался компилятор,
венгерка появилась во времена си, когда компилятор этим не очень хорошо занимался. и появилась она в API функциях, глянув на прототип которых можно (в теории) не читать MSDN. на практике - увы. IN/OUT никак не маркируются в большинстве случаев, т.е. совершенно непопятно - возвращаются ли тут данные или только передаются. и нужно ли занулять структуры перед их передачей? а явно передавать размер структуры через одно из ее полей - это как? т.е. из прототипа все равно ничего не понятно.

_DEN_
> Необходимость в венгерке говорит о том, что программист
> не в состоянии придумать внятного имени для объекта,
> из которого было бы ясно как этим объектом пользоваться.
полностью поддерживаю. даже названия API чего стоят.
попробуй объясни начинающим, что CreateFile - это типа fopen,
только намного круче типа и открывает, и создает, и еще
много чего может делать

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

 

kaspersky

void const* - in
void* - out

void foo(DATETIME const* date_and_time_that_must_be_zero_initialized); // Венгерка ушла не очень далеко от этого.

 

kaspersky

Правда есть у винды свой идиотизм. Например некоторые функции принимают одни и те же структуры как для чтения параметров некоего объектка, так и для записи. Например, это часто встречается во всяких common control. Там да, например для установки текста в list view из std::string, приходится делать const_cast, потому что указатель на текст в структуре не конст, потому что эту же структуру используют и для чтения параметров.

 

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

Код (Text):

1. CreateFileMapping(HANDLE hFile, ...);

то переменная hFile должна называться h(Ваше_название). Иначе явно нарушаются классические каноны хорошего стиля программирования. Кто не понял, прочтите "Совершенный код" Макконела.

kaspersky

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

Great
Перестань писать красным цветом, раздражает. Знаю что ты так делал на античате, но ты все таки васм с ним перепутал.

 

Osen

Бгагагагга)))) Это кто тебе сказал что WinAPI - канон хорошего стиля программирования?))))

Обязательно. Уже просто несусь со сверхзвуковой скоростью в дом книги. Для начала давай поднимем вопрос о компетентности Макконела относительно "Совершенного кода". Кто он такой чтобы рассуждать на такие темы?

 

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

Я бы на твоём месте ринулся в Дом книги, хорошая книга. Очень.

 

венгерка гадость в чистом виде. считаю что во многих случаях избыточна.
обозначать i как dwi или как uii считаю излишним, не говоря о таких перлах как
MY_SUPER_MEGA_PUPER_DWORD msmpdwi
предпочитаю давать информативные имена не с точки зрения указания типа, а с точки зрения указания функционального назначения переменных. плюс для случаев zeroinitialized писать коментарии.