Здравствуйте, Lexey, Вы писали:

G>>Как у вас просто все.

L>Ну да, а зачем себе и другим жизнь усложнять?
Согласен, это действительно ни к чему.

L>Таких баг мне еще ни разу ни ловить, ни видеть не приходилось, впрочем как и видеть такие уровни вложенности.
О, у нас их гнездо. Мечта любого баголова-любителя .

L>Максимум — уровня 4-5. И ловилось все отсилы за пару часов без каких-то диких трассировок стека. Гораздо большие проблемы обыно составляет исправление.
L>И размер под 50 мегов тут особой роли не играет — это же не один модуль.

Ну, , вообще-то один. Хотя это действительно роли не играет. Играет роль, что ты (например) в коде очень плохо разбираешься. И поэтому в процессе идентификации ошибки тебе попутно приходится делать reverse-engineering. А код старый, большой и страшный.

G>>И посмотрим, как тебе помогут "нормальные размеры". Кстати, а "нормальные" это сколько? 5, 10, 50, 100, 200? А ты уверен, что все
L>Да в общем-то нормально помогают. По крайней мере никогда не видел нужды в каких-либо префиксах (даже в стандартной венгерке).
L>Нормальные по моим меркам — строк до 30-40.
Значит твой код настолько хорош, что его не портит наличие/отсутствие префиксов. Такое бывает.

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

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

Здравствуйте, Gaperton, Вы писали:

L>>Таких баг мне еще ни разу ни ловить, ни видеть не приходилось, впрочем как и видеть такие уровни вложенности.
G>О, у нас их гнездо. Мечта любого баголова-любителя .

Предпочитаю все-таки свои писать, чем чужие ловить.

L>>И размер под 50 мегов тут особой роли не играет — это же не один модуль.

G>Ну, , вообще-то один. Хотя это действительно роли не играет. Играет роль, что ты (например) в коде очень плохо

8-( ). Что же это за зверь такой?

разбираешься. И поэтому в процессе идентификации ошибки тебе попутно приходится делать reverse-engineering. А код старый, большой и страшный.


G>>>И посмотрим, как тебе помогут "нормальные размеры". Кстати, а "нормальные" это сколько? 5, 10, 50, 100, 200? А ты уверен, что все
L>>Да в общем-то нормально помогают. По крайней мере никогда не видел нужды в каких-либо префиксах (даже в стандартной венгерке).
L>>Нормальные по моим меркам — строк до 30-40.
G>Значит твой код настолько хорош, что его не портит наличие/отсутствие префиксов. Такое бывает.

Может быть.

G>Повезло. Кроме шуток, тебе действительно повезло. Потому что код, на котором очевидно преимущество префиксов, это ужас, летящий на крыльях ночи. Это жвачка, прилипшая к твоему ботинку. Это труп, поддерживающий видимость жизни усилиями злых чорных магов-программистов. Это великий и ужасный LEGACY CODE.

Ну, в общем-то, наверное и с таким кодом приходилось иметь дело. Причем написанным на VB. Песец действительно полный, к счастью он все-таки был модульным и размеры были всего порядка мега.

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

Да нет, мне и у себя пока радостей хватает.

_D>>У меня не раз VA ставил раком MSVC и винды.

al>MSVC и без всякого VA может сама раком встать и Windows так-же поставить

А может не MSVC раком ставит, а та прога которую пишешь?

WH>Если ты не будешь этим заниматься то проект будет писаться на порядок дольше. Просто по тому что отладить 10 маленьких проще чем одну большую и в большой проще совершить ошибку.

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

И еще пара минусов: а) производительность, б) отладка (если ошибка произошла на низком уровне иерархии вызовов).

А вообще есть замечательное правило: золотой середины, и ненадо бросаться в крайности

Удачи,
Valery.

Здравствуйте, Gaperton, Вы писали:

G>Повезло. Кроме шуток, тебе действительно повезло. Потому что код, на котором очевидно преимущество префиксов, это ужас, летящий на крыльях ночи. Это жвачка, прилипшая к твоему ботинку. Это труп, поддерживающий видимость жизни усилиями злых чорных магов-программистов. Это великий и ужасный LEGACY CODE.
Хм. Я боюсь, что на примере старого и ужасного кода видны только его недостатки: он стар и ужасен. Или ты предлагаешь вносить венгерские префиксы в Старый и Ужасный код? Или ты думаешь, что использование префиксов экономически оправдано при написании Старого и Ужасного кода? Я думаю, что экономически оправдано написание Нового и Красивого кода, а в нем почему-то преимущества венгерских префиксов не видно.
Надежда на то, что благодарные потомки вознесут тебе оды за венгерку при том, что на качество кода ты просто забил, сродни надежде продать дерьмо, ежели его поперчить как следует.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Gaperton, Вы писали:

S>Хм. Я боюсь, что на примере старого и ужасного кода видны только его недостатки: он стар и ужасен.
Во первых, на примере старого и ужастного кода можно много чему научится. Особенно если вспомнить, что его писали люди, которые думали что пишут Новый и Красивый код.

А во вторых, я говорил не "видны", а очевидны. "Очевидно" — это значит понятно без дополнительных раздумий, объяснений и оговорок. А не "понятно" вообще.
"...код, на котором очевидно преимущество префиксов..." не означает что речь идет о единствнном примере где видны преимущества префиксов.

S> Или ты предлагаешь вносить венгерские префиксы в Старый и Ужасный код?
Нет.

S> Или ты думаешь, что использование префиксов экономически оправдано при написании Старого и Ужасного кода? Я думаю, что экономически оправдано написание Нового и Красивого кода, а в нем почему-то преимущества венгерских префиксов не видно.

Во первых, речь идет не о венгерских префиксах. Почитай вверх по ветке.

Во вторых, конечно-же, написание Нового и Красивого кода не всегда экономически оправдано. Написание коммерческого софта это всегда компромисс между (1) качеством, (2) бюджетом, (3) функционалом. Причем приоритеты диктуются потребностями бизнеса, а не желанием программера. Слепое предпочтение качеству без принятия в расчет остальных факторов способно убить проект. И тогда не из чего (да и не за что) будет тебе платить зарплату, несмотря на то, что ты написал Новый и Очень Красивый код.

Любой коммерчески успешный продукт — это всегда инженерный компромисс. А тебе наверно кажется, что единственная причина по который пишется Старый и Ужасный код, это когда кто-то "на качество кода просто забил"? Да нет, он появляется сам собой потому, что всегда есть более приоритетные задачи, и менее приоритетные. И времени всегда не хватает. И потому что начальство не дает работать ради Красивого Кода (и правильно делает — это бизнес, а не НИИ). И потому, что все очень умные поодиночке программисты не склонны до конца разбираються в очень красивом коде друг друга, когда его изменяют.

А также потому, что не все программисты являются гуру в области дизайна и технологий, и иногда ошибаются. И это правильно, — на ошибках они учатся, и это шанс стать гуру. Но вот код за ними никто не выбрасывает, он доводится серией клуджей до стабильного состояния и идет в релиз. А потом поддерживается. Почему? Да потому что это дешевле чем выбрасывать.

Во третьих, кому это "не видно"? Мне вот, например, видно преимущество префиксов на любом С++ коде — новом, старом, красивом, страшном. И не только мне, я знаю очень много людей, кто разделяет мое мнение. Ну и что с того?

S>Надежда на то, что благодарные потомки вознесут тебе оды за венгеркупри том, что на качество кода ты просто забил, сродни надежде продать дерьмо, ежели его поперчить как следует.

Звучит, как будто я призываю всех просто забить на качество кода, потому что за использование венгерки нам обещано отпущение всех грехов. Аминь! Правильно, так меня, мракобеса, по лбу, простой и доступной аналогией с перченым дерьмом.

Здравствуйте, Gaperton, Вы писали:


G>Вот простейший пример — одна из ситуаций, когда это помогает. Допустим мы ловим багу в малознакомом (чужом, и/или хорошо забытом) коде.

G>

G>void SomeClass::SetTimeRange( TimeRange i_exclusiveTimeRange )
G>{
G>// legacy code...

G>   TimeRange inclusiveTimeRange = i_exclusiveTimeRange;
G>   inclusiveTimeRange.SetEndTime( i_exclusiveTimeRange.GetEndTime() - oneMinute );

G>// legacy code...

G>   doSomething( inclusiveTimeRange );

G>// legacy code...

G>   doSomethingElse( i_exclusiveTimeRange );
G>}
G>

G>Мы остановились в брекпойнте в функции doSomethingElse. Понимаем, что ошибка вызвана неправильным значением входного параметра. Выходим в отладчике из функции doSomethingElse обратно в функцию SetTimeRange. Первая строчка, на которой останавливается взгляд, это doSomethingElse( i_exclusiveTimeRange ). Глядя на префикс параметра понимаем, что нам не надо смотреть по коду, как вычисляется i_exclusiveTimeRange, т. к. это входной параметр.

Позволю себе маленький вопрос. Последнее утверждение подразумевает, что входные параметры не модифицируются в теле функции. Есть ли гарантии, что весь legacy code написан с соблюдением этого правила? И почему бы тогда в описание формального параметра
не добавить const? (ну, два вопроса... )

Здравствуйте, Vladimir_K, Вы писали:

V_K>Здравствуйте, Gaperton, Вы писали:


G>>Вот простейший пример — одна из ситуаций, когда это помогает. Допустим мы ловим багу в малознакомом (чужом, и/или хорошо забытом) коде.

G>>

G>>void SomeClass::SetTimeRange( TimeRange i_exclusiveTimeRange )
G>>{
G>>}
G>>

G>>Мы остановились в брекпойнте в функции doSomethingElse. Понимаем, что ошибка вызвана неправильным значением входного параметра. Выходим в отладчике из функции doSomethingElse обратно в функцию SetTimeRange. Первая строчка, на которой останавливается взгляд, это doSomethingElse( i_exclusiveTimeRange ). Глядя на префикс параметра понимаем, что нам не надо смотреть по коду, как вычисляется i_exclusiveTimeRange, т. к. это входной параметр.

V_K>Позволю себе маленький вопрос. Последнее утверждение подразумевает, что входные параметры не модифицируются в теле функции. Есть ли гарантии, что весь legacy code написан с соблюдением этого правила?
Гарантий — никаких, есть надежда . Слава богу у нас это случается не часто (хотя было разок на моей памяти). Все-таки древние программисты были по большей части гуманны, и у них рука не поворачивалась модифицировать переменную с префиксом i_.

V_K> И почему бы тогда в описание формального параметра
V_K>не добавить const? (ну, два вопроса... )
Чорт. Вообще надо-бы, по уму-то если.

Здравствуйте, McSeem2, Вы писали:

MS>

MS>Венгерская запись целесообразна для языка ассемблера, в котором все, что вы знаете о переменной — это ее размер. Включение информации о типе в имя переменной позволяет вам контролировать правильность ее использования. Языки более высокого уровня типа С и С++ используют для этой цели объявление переменных.

При всем уважении к господину Голубу (мне очень нравится его книга), тут он не совсем прав.

Единственное внятное и разумное определение "уровня языка" для императивных языков я видел в книжке про архитектуру "Эльбрус-3". Архитектура заточена под эффективное выполнение программ на языках высокого уровня, поэтому им требовалось определение уровня языка. У них было интересное исследование на эту тему ("Они" — это Бабаян и компания). По результатам они постановили, что уровень языка определяется это развитостью его системы типов, и ничем больше.

Язык С с его слабым на грани отсутствия контролем типов — это язык низкого уровня (то же их вывод), вроде макроассемблера, только переносимый. Вывод подтверждается практикой его применения, — сейчас он используется для тех задач, для которых ранее традиционно применялся ассемблер. Голуб ошибается, ровняя С с С++. Соответственно, и дальнейшая его аргументация применительно к языку С весьма спорная.