Хорошо отношусь к любым нормальным нотациям. И даже не совсем из-за с ходу видимой типизации, а вот почему — когда человек держит какую-то модель именования сущностей в голове, он не станет в разных частях системы использовать свежевыдуманные произвольные конструкции типа:
файл а - std::string sMessage;
файл б - std::string MessageString;
файл в - std::string strMsg;
Читать потом всё это действительно неудобно — сбивает внимание на ненужные мелочи, отвлекает от идеи кода.
Для меня использование нотации в контексте проекта — то же самое, что приготовление доумента о терминах и соглашениях на фазе проектирования — некая помогалка выработать единый язык проекта. Сам я часто при переходе от проекта к проекту менял нотации по необходимости, но это мне совершенно не мешало. Время полной адаптауии к новой системе именования — неделя, может две.
Здравствуйте, Anatolix, Вы писали:
A>Здравствуйте, Stoune, Вы писали:
A>P.S. А если серьезно то зачем разбираться в программе в FAR, в VS с Visual Assist-ом с его демонстрацией типа переменной при наведении на нее курсора go to declaration/implementation гораздо удобнее
У меня в архиве разных проектов причём как от 5-ой, так и 6-ой так и 7-ой и даже от BC++5.0 около двух сотен наберётся, так мне что заинсталированые их всех держать прикажеш, а для того чтоб найти одно хорошую функцию (имени не помниш, так што поиск не катит) двух летней давности знаеш сколько ты потратиш времени только на загрузку визуальных средств, и заметь это только твой код, но уже через месяц, ты думаеш кто это писал. Студия у тебя не всегда под руками, а Блокнот, он на любой винде стоит.
Здравствуйте, Stoune, Вы писали:
S>...знаеш сколько ты потратиш времени только на загрузку визуальных средств, и заметь это только твой код, но уже через месяц, ты думаеш кто это писал.
Потратишь ровно одну секунду. Клац по файлу в фаре, и вот он у тебя уже в тудию загружен. Чего проще?
S>... Студия у тебя не всегда под руками, а Блокнот, он на любой винде стоит.
А зачем тебе код без студии?
Если нам не помогут, то мы тоже никого не пощадим.
Извините, люди, но раз речь зашла про книжку Алена, то очень хочется сказать (и скажу!) что автор этой книжки — нехороший человек. Единственное, что я у него перенял — разделение функций: //---------, а в остальном... это была наверное единственная книга, от которой меня чуть не стошнило: одни наезды причем на все подряд, и по OLE он там проехался, и по венгерскому соглашению... Ну и читайте распечатки чужого кода страниц на 20 и гадайте что такое это и что такое то.
Не стоит переходить реку вброд, если известно только, что ее глубина (средняя) 4 фута.
W>Извините, люди, но раз речь зашла про книжку Алена, то очень хочется сказать (и скажу!) что автор этой книжки — нехороший человек. Единственное, что я у него перенял — разделение функций: //---------, а в остальном... это была наверное единственная книга, от которой меня чуть не стошнило: одни наезды причем на все подряд, и по OLE он там проехался, и по венгерскому соглашению... Ну и читайте распечатки чужого кода страниц на 20 и гадайте что такое это и что такое то.
Книжка Голуба лежит у меня лет пять, но до сих пор многие моменты до сих пор популярны. Просто кто-то никак не может научиться на собственных ошибках.
Венгерская нотация нарушает одно важное правило, что MS никак не может/не хочет понять — именование в соответствии с назначением, а не реализацией.
Например, мы пишем метод, который что-то сортирует, причем стандартный метод использовать не получается. Мы сами реализуем метод сортировки пузырьком (мало записей) и называем его bubbleSortCustomRecords(). Но потом объемы данных растут, поэтому нам приходится писать quickSortCustomRecords(), в итоге нужно исправлять все места использования предыдущего метода.
В то время как метод sortCustomRecords() избавил бы нас от необходимости знать лишние детали, да упростил изменения.
Так и с венгерской нотацией. Сначала мы добавили m_iPosition (лично меня тошнит от этого m_, смысла ноль, а точнее минус, т.к. соседствует с нарушением инкапсуляции), а потом поняли, что нужна большая точность, в итоге переименовываем в m_dblPosition.
Кроме того, что все объявления типов придется менять, так еще и имена править.
W>Извините, люди, но раз речь зашла про книжку Алена, то очень хочется сказать (и скажу!) что автор этой книжки — нехороший человек. Единственное, что я у него перенял — разделение функций: //---------, а в остальном... это была наверное единственная книга, от которой меня чуть не стошнило: одни наезды причем на все подряд, и по OLE он там проехался, и по венгерскому соглашению... Ну и читайте распечатки чужого кода страниц на 20 и гадайте что такое это и что такое то.
Я Пастернака, естественно, не читал, но я скажу.
Горячо согласен с вами, wtom. И вы, и я, видимо, считаем, что код пишется в первую очередь для чтения, а уже во вторую — для компиляции. С этих позиций венгерская нотация очень удобна.
В самом деле: чей код вы видите чаще всего? Разве не мелкософтовый? И разве не они пользовались в.н. везде — от MSDN до сырцов своих DirectX SDK Samples?
Я всегда придерживался венгерской нотации, потому что хотел придать своему коду товарный вид. А это подразумевает лёгкость его чтения. Ну если человек читал (и понимал!) код из MSDN, из samples, то мой код, выглядящий сходным образом, он должен понимать наверняка. Иными словами: следуем за модой, и люди к вам потянутся. Авоськи функциональнее и рациональнее, но в магазин люди ходят с пластиковыми пакетами. Производители авосек в ауте!
Далее, библиотеки (распространяемые в виде сырцов) надо писать придерживаясь какой-то одной нотации, разве нет? И если это будет не венгерская, то какая?
Сейчас же, с переходом на COM и .NET нужда в в.н. действительно отпадает. Попытаюсь сформулировать, почему:
Мультиязычная поддержка. Кто любит float, кто single. Как быть?
Кому охота видеть ваши свойства в m_-виде? Из другой среды это выглядит ужасно.
Имя переменной — сама по себе информация в .NET, и может использоваться по ходу дела. Конечному пользователю видеть, к примеру, "Names" предпочтительнее, чем "m_lpaszNames".
Несмотря на это, венгерской нотацией по прежнему можно. Послать пасквилянтов с их single, на свойство повесить Get/Set пару, манипулирующую m_-переменной и т.п., но как раз это становится искусственным. Бегом за новой модой!
V>Книжка Голуба лежит у меня лет пять, но до сих пор многие моменты до сих пор популярны. Просто кто-то никак не может научиться на собственных ошибках.
V>Венгерская нотация нарушает одно важное правило, что MS никак не может/не хочет понять — именование в соответствии с назначением, а не реализацией.
V>Например, мы пишем метод, который что-то сортирует, причем стандартный метод использовать не получается. Мы сами реализуем метод сортировки пузырьком (мало записей) и называем его bubbleSortCustomRecords(). Но потом объемы данных растут, поэтому нам приходится писать quickSortCustomRecords(), в итоге нужно исправлять все места использования предыдущего метода. V>В то время как метод sortCustomRecords() избавил бы нас от необходимости знать лишние детали, да упростил изменения.
V>Так и с венгерской нотацией. Сначала мы добавили m_iPosition (лично меня тошнит от этого m_, смысла ноль, а точнее минус, т.к. соседствует с нарушением инкапсуляции), а потом поняли, что нужна большая точность, в итоге переименовываем в m_dblPosition. V>Кроме того, что все объявления типов придется менять, так еще и имена править.
V>--
V>Владимир.
Как хотите, но _мой_ опыт _мне_ показывает, что легче заменить все m_nPosition, на m_fPosition используя Find&Replace (учитывая еще и то, что при нормальном проектировании это приходится делать крайне редко, чем писать Position, а потом через этак через месяц судорожно листать код в поисках ответа, объект это какого-то класса или указатель на него или целочисленная переменная, или еще что-то. И, например, легче инициализировать структуру из какой-либо билиотеки, если по имени члена сразу можешь определиьть ее тип, чем постоянно переключаться с кода на документацию и обратно. Для ОО языков это тем более усиливается, (разочарую, наверное, человека который в этом топике открыл для себя, почему для ОО языка префиксы теряют смысл) если вы в процессе поиска типа Position где-то наткнетесь на int range = Position — AnotherPosition, это вам абсолютно ни о чем не скажет. Естественно все споры о стиле оформления кода, в основном, бессмысленны, все так говорят, и все спорят. Но я _vovin'a код читать не буду.
Не стоит переходить реку вброд, если известно только, что ее глубина (средняя) 4 фута.
Здравствуйте, McSeem2, Вы писали:
MS>Полностью согласен. Вот выдержка из книги Алена Голуба "ВЕРЕВКА ДОСТАТОЧНОЙ ДЛИНЫ, MS>ЧТОБЫ ВЫСТРЕЛИТЬ СЕБЕ В НОГУ". Книгу можно легко найти по вышеуказанным ключевым словам.
Отличный образец такого подхода можно наблюдать в любом предлагаемом Microsoft примере программы, хотя эта проблема ни в коем случае не ограничивается корпорацией Microsoft. Все демонстрационные программы Microsoft Windows включают тип переменной в ее имя.
А вот другая выдержка (по памяти):
(С)Николай Носов.
— Вот когда полетишь на Луну, — сказали коротышки профессору Звёздочкину, — тогда и будешь выступать на трибуне. А пока посиди здесь, на травке.
Когда гражданин Голуб будет продвигать свои программы по всему миру так, как это делает MS, тогда его и надо будет читать, как "Отче наш". А пока писать надо в стиле MS. Больше шансов, что ваш код поймут. Если, конечно, вы заинтересованы, чтобы ваш код читали и понимали.
Здравствуйте, Снорк, Вы писали:
С>Когда гражданин Голуб будет продвигать свои программы по всему миру так, как это делает MS, тогда его и надо будет читать, как "Отче наш". А пока писать надо в стиле MS. Больше шансов, что ваш код поймут. Если, конечно, вы заинтересованы, чтобы ваш код читали и понимали.
Что-то меня в последнее время начинает тошнить от программ, распространяемых MS. Не заметно, чтобы использование венгерской нотации им хоть сколько-нибудь помогало.
Здравствуйте, Lexey, Вы писали:
L>Что-то меня в последнее время начинает тошнить от программ, распространяемых MS. Не заметно, чтобы использование венгерской нотации им хоть сколько-нибудь помогало.
Даже если все мелкомягкие программы — полный отстой с технической точки зрения (что спорно), а их победное распространенение по миру обеспечивалось маркетологами, а не нотациями и прочей программной хренью, смысл сказанного мною не меняется. Какая разница, как они достигли популярности? Главное, что они — законодатели мод.
Впрочем, они сами отказываются ныне от венгерской нотации. Как тут уже заметили, в GDI+, например.
>относится к сабжу и к префиксам вообще. Мне почему-то кажется, что в приходом всевозможных VAssist-ов >реальная необходимость в этом постепенно отмирает. И держится это всё на программистах "старой школы". Но я
включение информации о типе в имя в языках ООП со строгой типизацией абсолютно бесполезно. если осмысленно выбраны идентификаторы то и так все понятно. существительное — имя сущности(класса). глагол — имя метода.
для простых типов тоже все понятно что Count должно быть числом а FileName — строкой.
Здравствуйте, DarkGray, Вы писали:
DG>Здравствуйте, Снорк, Вы писали:
С>>С "%s" всё понятно. А с "его возраст — %i лет, его з/п — %.2f$, имя ему — %s" как быть?
DG>В форуме по C++ я уже постил класс, который типизированным образом работает с форматной строкой: DG>
DG>CString (или std::string) = CFormatString("его возраст - %i лет, его з/п - %.2f$, имя ему - %s")
DG> << age << зарплата << name;
DG>
Что-то я всё равно недопонимаю. За отсутствием Река, может вы объяснитесь? >Короче, тип либо ясен из контектса, либо не важен.
Чем ваш класс CFormatString безопаснее принтфа? Тем что сомнительной конструкции "..." нет?
Всё высказывание Река можно, получается, свести к:
Конструкция vararg небезопасна.
Чтобы она стала безопаснее, можно пользоваться венгеркой (учитывается размер и т.п.)
Так же можно написать самовозвращающий объект-поток и вообще её исключить
Вывод: в ОО системе вегерка не нужна.
Что понимать под безопасностью? Если не уконтролировать типы, в любом случае получаем ошибку ВРЕМЕНИ ИСПОЛНЕНИЯ!
Чтобы избежать таких вещей, венгерка по-прежнему нужна!
Я не сторонник в.н. в современных системах, но аргументацию Река не догоняю.
Здравствуйте, Снорк, Вы писали:
С>Что понимать под безопасностью? Если не уконтролировать типы, в любом случае получаем ошибку ВРЕМЕНИ ИСПОЛНЕНИЯ!
Ошибка времени исполнения бывают разные — одно дело при ошибке исполнения снесло часть стека и запортило кусок памяти, совсем другое дело, если выскочило документированное исключение.
в первом случае — мы получаем бардак, а во втором случае — детерминированное поведение.
ошибка в работе с varargs приводит к первому случаю, ошибка в вызове типизированного stream-а или FormatString приводят к детерминированному поведению.
После возникновения детерминированной ошибки — программа может продолжить/возобновить свою работу, в случае сноса стека — это невозможно.
Здравствуйте, DarkGray, Вы писали:
DG>Ошибка времени исполнения бывают разные — одно дело при ошибке исполнения снесло часть стека и запортило кусок памяти, совсем другое дело, если выскочило документированное исключение.
Я так и предполагал, что речь идёт о разных классах ошибок. Хотел даже сразу написать об этом, но поленился.
Значит без catch нифига работать не будет?
Так тогда следует писать, по-моему, так: давайте дружно пользоваться исключениями, вместо венгерки — try/catch. Впрочем, так никто и не напишет, потому как абсурдность видна неевооружённым взглядом.
Вопрос-то по-прежнему стоит: а как быть тем, кто вообще ошибок не хочет? Ни стековых, ни путаницы типов? Им слежение и контроль за типами заменить нечем! Я по-прежнему аргументацию не понимаю.
Могу согласиться, что Вассисты и глядение в декларацию класса венгерку заменят, но вот что >тип либо ясен из контектса, либо не важен
понять не могу. Одно дело — критерий Лисков, а совем другое вместо принтфа — CStringFormat.
Нет, я сам считаю, что тип не должен быть важен, но и тут венгерка вполне на месте — указывать базовый класс данной гомоморфной иерархии.
Здравствуйте, Снорк, Вы писали:
С>понять не могу. Одно дело — критерий Лисков, а совем другое вместо принтфа — CStringFormat.
ok. Давай разберем поведение CStringFormat-а.
Все те типы, которые выводятся в printf-е, а это int, float, double, bool, string в StringFormat-е выводятся без рантаймовых ошибок в любом случае! Что не скажешь про printf.
При этом, как фичу, StringFormat позволяет выводит, какие-то свои типы, здесь уже могут быть рантайм ошибки.
Ну запрети ты эту фичу, и у тебя получится,
что при выводе через StringFormat тип знать не надо, и при этом никаких ошибок в runtime-е у тебя не будет, а с printf-ом ты вынужден знать тип параметров, да еще в случаи ошибки все чревато падением программы.
Здравствуйте, Снорк, Вы писали:
С>Вопрос-то по-прежнему стоит: а как быть тем, кто вообще ошибок не хочет? Ни стековых, ни путаницы типов? Им слежение и контроль за типами заменить нечем! Я по-прежнему аргументацию не понимаю.
1. При "нормальном" проектировании программы, а такжи при "нормальном" языке (что-то большее, чем C) — рантаймовых ошибок в виде неправильного преобразования типов — не будет.
printf такому нормальному проектированию мешает.
2. От рантаймовых ошибок в общем случае ты все равно никуда не денешься: а если деление на ноль? память кончилась? или файла на диске не оказалось?
Здравствуйте, DarkGray, Вы писали:
DG>ok. Давай разберем поведение CStringFormat-а. DG>Все те типы, которые выводятся в printf-е, а это int, float, double, bool, string в StringFormat-е выводятся без рантаймовых ошибок в любом случае! Что не скажешь про printf.
// В объявлении класса
CString tax(_T("1000$"));
// В его методе (другой файл, строка так пятитысячная)
CString (или std::string) = CFormatString("его возраст - %i лет, его з/п - %.2f, имя ему - %s")
<< age << tax << name;
Разве использование хоть какого-нибудь класса может избавить от такой ошибки? Даже если не вылетит исключение, строка не будет корректно отформатирована, что уже — run-time ошибка. По мне, так лучше принтф, он хоть всё повешает, а некорректную строку можно и в final release пропустить.
Используя венгерку, получаем strTax / fTax / iTax, что мешает нам написать приведённую выше ерунду.
Конечно, если глаза не растут из зада и с помощью Вассиста мы отследим такую ошибку, но коим образом правильная ОО-организация заменяет нам венгерку?
илиДажеДва 
Если нам не помогут, то мы тоже никого не пощадим.
Не заметно, чтобы использование венгерской нотации им хоть сколько-нибудь помогало.
