F>>Хорошо, тогда сначала. А что тогда есть "венгерка" (т.е. более менее серьезный документ, на который можно было бы ссылаться)? S>Здесь
S>
Ужасно. Похоже доктор Саймони все еще не поднялся над уровнем ассемблера.
Если при принятии на работу программиста я вижу такой ужасный стиль, как в его примере, то это означает автоматический отсев. Правда, я думаю, Саймони меня тоже сразу бы отсеял по идеологическим соображениям.
Вопрос: как понимать These are often combined, as in: (ниже по тексту).
Венгерка комбинируется с неким зверем по имени Coding style conventions, или префиксы комбинируются, являясь частью венгерки? Мне кажется, что скорее второе.
Венгерка зародилась ещё во времена DOS и, по понятным причинам, m_ и IXXX включать в себя первоначально не могла. С этим я согласен. Можно ли считать тот код, который генерирует шестая студия, Win32-версией венгерки, вот в чём вопрос.
S>>>Здесь V>>Ужасно. Похоже доктор Саймони все еще не поднялся над уровнем ассемблера.
DG>Выставленные оценки впечатляют. Почти половина поставила 1 из 9, столько же — 9 из 9
А Саймони идет на rsdn и всем, кто ставил единицу, влепит по нулю. =)
РМ>Непонятно, зачем там сделаны i f и s? Это же дублирование информации о типе параметра, и чего делать если не совпадет, повешать систему как принтф, подставить вместо парамтра слово матом или кинуть исключение, которое никто не поймает?
Это для совместимости с printf-ом. В реальной жизни соответствия типов не проверяются, но, например, встречая %x, CFormatString перерубается в вывод шестнадцатеричный чисел и т.д.
РМ>А еще не плохо бы в таком классе нумеровать параметры. Иначе преимуществ перед std::ostringstream 0. РМ>
РМ>CString (или std::string) = CFormatString("его возраст - {0} лет, его з/п - {1}, имя ему - {2}") << age << std::setprecision(2) << зряплата << name;
РМ>
"std::setprecision(2)" — это уже моветон. Зачем тогда нужна форматная строка?
хотелось как раз все форматирование выкинуть в саму форматную строку.
CString (или std::string) = CFormatString("его возраст - {0} лет, его з/п - {1:f2}, имя ему - {2}")
<< age << зряплата << name;
ps
Оба варианта(с процентами и с номерами) CFormatString-а постились в исходниках в виде идеи в форуме c++. Можешь поискать.
Здравствуйте, Micker, Вы писали:
M>Здравствуйте, Constructor, Вы писали:
M> C>>В констркуции anObject.instance понятно. А вот в теле функции строчек в 20 и поболее уже не понятно!
M>Дак и не зачем такие большие функции плодить. M>Функция должна занимать 5-10 строчек. Так ещё можно контролировать код. А при 30 строчках, ты не в переменных, так в алгоритме ошибёшся. Преффиксы, в данном случае, просто загоняют проблему в даль.....
Сомнительно...
Если заниматься постоянно функциональной декомпозицией методов, то когда же проект сдавать?
Или понятие сроков в природе остсутствует?
Здравствуйте, _vovin, Вы писали:
S>>Насколько я понимаю противники венгерской записи предлагают "верблюда" (особенно для C# и проч). Но тут появляется проблема. Допустим я пишу объект на C# в котором есть проперти Count. Как мне обозвать поле класса, которое его представляет? Насколько я понимаю count. Однако когда мы этот класс начнем юзать в VB.NET, мы поимеем проблемы — он нечувствителен к регистру. Честно говоря я неуверен, что он вообще будет работать (поставить эксперимент что ли )... Поэтому имхо венгерку рано хоронить (по-крайней мере m_xxx и проч....).
V>Если m_ используется снаружи, то это нарушение инкапсуляции.
Например поле protected и я наследуюсь от этого класса. Поле становится для меня (писателя класса-наследника) видимым.
V>Если внутри метода, значит это code smell — большой метод, в котором ничего не понять. На крайний случай можно применять префиксы для параметров — _count, aCount...
Хм... А чем параметры принципиально отличаются от обычных переменных (с точки зрения смысла алгоритма)?
S>>Ну и еще одна вещь, где венгерка не собирается отступать — объявления интерфейсов (Ixxx)... V>Из моих проектах она уже давно ретировалась.
V>IStream — Streamable V>IPrint — Printable
Пишем COM компонент. Добавляем ко-класс, ну например, Bitmap. Интерфейс обзывает Bitmapable?
S>>А вообще, есть ли другие альтернативы? V>Читабельные имена.
Читабельными они должны быть вне зависимости от нотации...
V>А вообще это не альтернатива, а исправление code smell — вписывание в идентификаторы информации о типе/области видимости, а не ролей.
Все-таки не понимаю, чем это мешает. Если название переменной не MyCoolVariable или чего хуже xx12, то читабельность нисколько не портится.
V>Плюс неявный дефект, который сопутствует нотации — плохой дизайн/качество кода.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, swamp, Вы писали:
S>>Допустим я пишу объект на C# в котором есть проперти Count. Как мне обозвать поле класса, которое его представляет? Насколько я понимаю count. Однако когда мы этот класс начнем юзать в VB.NET, мы поимеем проблемы — он нечувствителен к регистру.
AVK>Как ты интересно собрался в VB юзать приватное поле?
Приватное никак (ну или может через рефлексию ), а protected — запросто. Например унаследовавшись от этого класса.
S>>Ну и еще одна вещь, где венгерка не собирается отступать — объявления интерфейсов (Ixxx)...
AVK>Ты по моему путаешь венгерку с префиксами вобще. Венгерка это префиксы, отражающие тип переменной. m-xxx и IXxx венгеркой не являются.
Да? Я вообще полагал, что венгерская нотация — это такой подход к именованию идентификаторов, который подразумевает использование префиксов (неважно для какой цели). В MSDN есть technical article под названием Hungarian Notation. Вот оттуда выдержка:
A note from Dr. GUI: Long, long ago in the early days of DOS, Microsoft's Chief Architect Dr. Charles Simonyi introduced an identifier naming convention that adds a prefix to the identifier name to indicate the functional type of the identifier.
This system became widely used inside Microsoft. It came to be known as "Hungarian notation" because the prefixes make the variable names look a bit as though they're written in some non-English language and because Simonyi is originally from Hungary.
То есть слово "Венгерская" здесь от того, что мы делаем название непохожим на обычный язык, т.е. пользуемся префиксами и т.п...
Впрочем неважно. Важна проблема — как разрулить ситуацию, когда в одном месте есть несколько идентификаторов, которые должны называться одинаково (с точки зрения смысла программы). Эта ситуация может быть не только при вышеописанной ситуации. Например параметры конструктора:
SomeClass(int count)
{
m_count = count;
}
Как сделать без префиксов? Не называть же параметр countOfSomeClass
Здравствуйте, swamp, Вы писали:
AVK>>Ты по моему путаешь венгерку с префиксами вобще. Венгерка это префиксы, отражающие тип переменной. m-xxx и IXxx венгеркой не являются.
S> Да? Я вообще полагал, что венгерская нотация — это такой подход к именованию идентификаторов, который подразумевает использование префиксов (неважно для какой цели). В MSDN есть technical article под названием Hungarian Notation. Вот оттуда выдержка:
S>
S>A note from Dr. GUI: Long, long ago in the early days of DOS, Microsoft's Chief Architect Dr. Charles Simonyi introduced an identifier naming convention that adds a prefix to the identifier name to indicate the functional type of the identifier.
Здравствуйте, _wqwa, Вы писали:
W>Сомнительно...
Напрасно. W>Если заниматься постоянно функциональной декомпозицией методов, то когда же проект сдавать? W>Или понятие сроков в природе остсутствует?
Если ты не будешь этим заниматься то проект будет писаться на порядок дольше. Просто по тому что отладить 10 маленьких проще чем одну большую и в большой проще совершить ошибку.
... << RSDN@Home 1.0 beta 5 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WH>Если ты не будешь этим заниматься то проект будет писаться на порядок дольше. Просто по тому что отладить 10 маленьких проще чем одну большую и в большой проще совершить ошибку.
Ну хорошо. Вот если тебе не сложно, загляни в свои проект и скажи, сколько строчек занимает самая большая функция, и сколько -- в среднем.
Здравствуйте, dmz, Вы писали:
P>>Раз тут развернулось обсуждение префиксов, хотелось бы узнать, как сейчас прогрессивная общественность относится к сабжу и к префиксам dmz>Венгерскую нотацию — давить. Почему — читать Голуба. Который Аллен.
Венгерскую нотацию — давить. Полностью согласен с dmz.
Здравствуйте, _wqwa, Вы писали:
W>Ну хорошо. Вот если тебе не сложно, загляни в свои проект и скажи, сколько строчек занимает самая большая функция, и сколько -- в среднем.
Смотрю мой COM сервер примерно треть 1-3 строки, треть 5-10 строк, остальное имплементация интерфейсов(проверка входных параметров, проверка состояния обьекта, выделение памяти...короче набегает а главное не разделить ) 15-30 строк за редким исключением в ту и другую сторону. Правда есть несколько монстров 60-120 но там switch кототый можно разве что разнести по отдельным case'ам но я решил что куски кода и так достаточно разделены и не стал извращаться.
... << RSDN@Home 1.0 beta 5 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, swamp, Вы писали:
V>>Если m_ используется снаружи, то это нарушение инкапсуляции. S> Например поле protected и я наследуюсь от этого класса. Поле становится для меня (писателя класса-наследника) видимым.
Тоже нарушение инкапсуляции — наследник может быть в другой компоненте.
Do not use instance fields that are public or protected (Public or Protected in Visual Basic). If you avoid exposing fields directly to the developer, classes can be versioned more easily because a field cannot be changed to a property while maintaining binary compatibility. Consider providing get and set property accessors for fields instead of making them public.
Здравствуйте, _wqwa, Вы писали:
W>Здравствуйте, Micker, Вы писали:
M>>Здравствуйте, Constructor, Вы писали:
M>> C>>>В констркуции anObject.instance понятно. А вот в теле функции строчек в 20 и поболее уже не понятно!
M>>Дак и не зачем такие большие функции плодить. M>>Функция должна занимать 5-10 строчек. Так ещё можно контролировать код. А при 30 строчках, ты не в переменных, так в алгоритме ошибёшся. Преффиксы, в данном случае, просто загоняют проблему в даль.....
W>Сомнительно... W>Если заниматься постоянно функциональной декомпозицией методов, то когда же проект сдавать? W>Или понятие сроков в природе остсутствует?
А как вы считаете, какое соотношение времени на проектирование и на кодирование нормалное? 1:100 ?
Вы из тех кто рвётся в бой — покодируем-покодируем, потом ошибочки поищем? потом бросим и перекодируем?
Жизнь, как игра —
идея паршивая,
графика обалденная...
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Micker, Вы писали: M>>Удалые хлопцы могут и ещё наворотить к имени чёрт знает что... M>>Например, вспомните иерархии классов С++ : там префик принято ещё ставить по производителю или автору (если C-то вероятно MFC, если T-то Борлонд и т.д.). А то что для этого есть понятие namespace не все помнят... S>Нет, это не так. S>Обе библиотеки вводят свои coding conventions. Друг к другу эти конвенции не имеют никакого отношения. У борланда префикс T сделан, чтобы отличать вызов класс-методов от вызовов методов объекта и квалификации имени юнита.
Ну и это правильно? Зачем вообщем-то это необходимо различать? Вспомните Страуструпа, глава "Роли классов", можно Элджера почитать...
Жизнь, как игра —
идея паршивая,
графика обалденная...
Здравствуйте, Micker, Вы писали:
M>Ну и это правильно? Зачем вообщем-то это необходимо различать? Вспомните Страуструпа, глава "Роли классов", можно Элджера почитать...
А можно вспомнить, что VCL написана на Паскале, и осознать ограничения применимости Страуструпа и Элджера.
Ребята, "просто так" ничего не бывает.
Все конвенции кодирования призваны улучшить читаемость кода человеком при помощи предоставления подсказок о семантике элементов. Часть семантики обеспечивается синтаксисом конкретного языка, и в таких случаях изобретение избыточных конвенций — это членоудлинительство.
В Паскале есть некоторые семантические неопределенности, которые затрудняют чтение программ. Для их разрешения были придуманы конвенции VCL. Префиксы имен классов, приватных полей, традиция называть обработчики On* и.т.д. — это все сделано именно для этого.
В CBuilder часть этих конвенций перекочевала вместе с VCL. Использование их там является не намного меньшим бредом, чем использование венгерки в плюсах или жабе.
Ну, CBuilder — это вообще выдающийся пример теоремы Стеклова. Не надо смешивать водку и пиво, хотя по отдельности оба напитка просто великолепны.
З.Ы. Для справки: теорема Стеклова из квантовой механики формулируется так: "Коммутатор операторов спиртных напитков с различной крепостью отличен от нуля". Из этого, в частности, следует принципиальная неизмеримость одновременно каждого из воздействий, например, пива и водки.
... << RSDN@Home 1.0 beta 6 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, swamp, Вы писали:
S>>>Насколько я понимаю противники венгерской записи предлагают "верблюда" (особенно для C# и проч). Но тут появляется проблема. Допустим я пишу объект на C# в котором есть проперти Count. Как мне обозвать поле класса, которое его представляет? Насколько я понимаю count. Однако когда мы этот класс начнем юзать в VB.NET, мы поимеем проблемы — он нечувствителен к регистру. Честно говоря я неуверен, что он вообще будет работать (поставить эксперимент что ли )... Поэтому имхо венгерку рано хоронить (по-крайней мере m_xxx и проч....).
V>>Если m_ используется снаружи, то это нарушение инкапсуляции.
S> Например поле protected и я наследуюсь от этого класса. Поле становится для меня (писателя класса-наследника) видимым.
Кстати говоря, наследование, это единственный приемлемый и официально одобренный способ нарушения инкапсуляции.
Поэтому сильно увлекать им, все-таки, не стоит.
Но даже в это случае, непонятно, зачем может понадобится префикс m_. Если исходя из назначения класса и вида метода (например, не вмещается на один экран) непонятно, где находится переменная и что она делает, то это проблема дизайна.
V>>Если внутри метода, значит это code smell — большой метод, в котором ничего не понять. На крайний случай можно применять префиксы для параметров — _count, aCount...
S> Хм... А чем параметры принципиально отличаются от обычных переменных (с точки зрения смысла алгоритма)?
Непринципиально. Это для тех, кому хочется быстро различать параметры и все остальное.
S>>>Ну и еще одна вещь, где венгерка не собирается отступать — объявления интерфейсов (Ixxx)... V>>Из моих проектах она уже давно ретировалась.
V>>IStream — Streamable V>>IPrint — Printable
S> Пишем COM компонент. Добавляем ко-класс, ну например, Bitmap. Интерфейс обзывает Bitmapable?
Это smell модели COM-а.
В нем приходится заводить интерфейс, одноименный классу. Было бы логичнее назвать его именно Bitmap, а остальные интерфейсы, которые "подмешиваются" к другим классам, называть с окончанием -able.
S>>>А вообще, есть ли другие альтернативы? V>>Читабельные имена.
S> Читабельными они должны быть вне зависимости от нотации...
При этом именно такая нотация становится излишней и даже вредной.
V>>А вообще это не альтернатива, а исправление code smell — вписывание в идентификаторы информации о типе/области видимости, а не ролей.
S> Все-таки не понимаю, чем это мешает. Если название переменной не MyCoolVariable или чего хуже xx12, то читабельность нисколько не портится.
Когда я вижу у своих программистов подобный идентификатор (который говорит о структуру, но не о назначении), я спрашиваю, попробуй сказать мне, для чего он предназначен одним предложением. После этого прошу сократить фразу до одного-трех слов. Таким образом, m_tabFirst привращается в DetailsTab, m_paneUpper в SearchPane и т.д.
V>>Плюс неявный дефект, который сопутствует нотации — плохой дизайн/качество кода.
S> Какая связь между дизайном и нотацией?
Наличие венгерской нотации может оправдываться плохим дизайном. Хороший дизайн может исключить излишнюю нотацию.
Здравствуйте, Sinclair, Вы писали:
S>А можно вспомнить, что VCL написана на Паскале, и осознать ограничения применимости Страуструпа и Элджера.
Сорри, Не совсем в курсе о теме спора: что такое VCL я не знаю, а на Паскале ничего профессионально не писал.
Склоняюсь к мысли, что в некоторых языках нотация типа Венгерки применима, даже помогает.
Но при этом, в С++ всегда можно обойтись без неё. С++ достаточно могущ и в нём есть средства, которые позволяют делать код чистым и прозрачным не прибегая к его загрязнению различными префиксами, суффиксами и нафиксами. Я уверен, что верная декомпозиция позволяет писать функции "умещающиеся на ладошкее". А применение нотаций делает код более жестким для изменения.
Возможно, что исключением станет пример функции со switch/case"ами. Но это тема отдельного спора. Полагаю, что при верном дизайне можно избавится от этого наследия C путем применения паттерна Command или Visitor. Хотя не стану утверждать, что это всегда возможно...
S>Ребята, "просто так" ничего не бывает.
Точно! Историческая совместимость с какими-то старыми вещами — дела благородное, но не дешовое. И если нотация пришла в С++ от Паскали (в какой-нить библиотеке), то это и есть расплата, за эту совместимость...
S>Все конвенции кодирования призваны улучшить читаемость кода человеком при помощи предоставления подсказок о семантике элементов.
Безусловно, ученик у которго есть шпаргалка, лучше напишет конторльную,
но ученик который понимает тему способен на получения больших результатов!
S> ... членоудлинительство.
Ну Вы и загнули!
Жизнь, как игра —
идея паршивая,
графика обалденная...
), а protected — запросто. Например унаследовавшись от этого класса.
) 15-30 строк за редким исключением в ту и другую сторону. Правда есть несколько монстров 60-120 но там switch кототый можно разве что разнести по отдельным case'ам но я решил что куски кода и так достаточно разделены и не стал извращаться.
