C>ну и что, что написал? C>если это только для отладки, то и сам так сделал бы. C>вообщем если код будет компилиться только в отладочной версии и только под винду, то нормально (ну разве что выделить это в макрос/ф-цию, не размножать его по проекту), ну а в релиз такое попадать не должно. Так что сначала скажите какие требования перед товарищем поставили, а уже потом думать можно "что делать"
я требований не ставил, т.к. он не есть мой подчиненный. но о том, что это должно работать и винде, и в линуксе, и в релизе, и дебаге, он в курсе
LMA>У меня создается впечатление, что Вы просто не знаете что это за константы и от этого начинаете злится на сотрудника.
LMA>Собственно не понятно, что именно Вам не нравится в этом коде (например, если весь проект усыпан кодом, который так и так не под MS работать не будет, то почему бы и нет).
LMA>Как Вам уже писали Выше, Вам следовало бы предложить свой вариант.
мой вариант — отдебажить код, а не городить заплатки
K>Нормальный код. Единственное, нужно магические числа задефайнить и скобки поставить K>*((int*)ici_os.a_top[-1]). K>Не было сказано на каком языке эта программа. Если на С, то проблем вообще нет. Это для С нормально. K>Ну и добавить немного коментов.
K>p.s. люди, которые сразу кидаются увольнять таких сотрудников или сильно бить палками — реально неадекватны.
Если бы я узнал, что такой нормальный код присутствует в ПО самолетов, то испугался бы летать.
Здравствуйте, ancient, Вы писали:
A>Уже через полгода даже сам автор обычно не может вспомнить, что же это за "знакомые каждому" константы.
Ты путаешь общий случай и конкретный, который является исключением для общего.
A>А если константа используется неоднократно по коду?
А имя её будет в этом случае использоваться сколько раз? Ещё раз повторю: значение данной константы говорит больше, чем любое придуманное для нее имя — вот в чем дело.
A>А если ее потом поменять захочется? (К примеру, MS вдруг захочет в новой версии компилятора другим значением стек заполнять)
А если имя константы поменять захочется?
A>Кстати, ты число "пи" тоже в программах циферками пишешь?
Число "Пи" известно как число "Пи". А число 0xfdfdfdfd известно как число 0xfdfdfdfd.
A>А сделай их именованными константами (отл., хор., и т.д.), и неожиданно обнаружишь, что программу практически не надо менять, чтобы учесть в ней американскую систему оценок.
Чушь полная, ибо однозначного соответствия между системами оценок все равно не будет. Такое лишь уменьшит читабельность программы в надежде, что такое когда-нибудь понадобится. Когда выяснится, что нужно на самом деле (а не голословно в надежде, что другого ничего менять не придется), нужно будет просто сделать рефакторинг.
LMA>>В данном конкретном случае использование именованных констант привело бы к запутыванию, а не улучшению читабельности (при работе с дампами памяти эти константы обычно не заменяются на имена, поэтому узнаются программистами сходу). A>В промышленном программировании нет "данных конкретных случаев". Есть общие подходы, которые просто тупо работают, независимо от случая. Например, правило, что _все_ (то есть абсолютно все) константы в программе надо именовать. Тот, кому придется за тобой поддерживать твой код, меньше всего захочет разбираться в твоих персональных "конкретных случаях".
Общих правил без исключений как раз нет; есть люди, у которых есть большие комплексы, потому что в свое время их больно били по рукам, когда они использовали "не то", "не там" и "не тогда". Нарушение таких правил — это нормально; не нормально — это когда человек нарушает такие правила, не понимая того, какие правила он нарушает и к чему это приведет.
Обрати внимание, сколько человек по данному коду сразу поняли в этой ветке о каких значениях идет речь, а если бы вместо значений стояли бы именованные константы — то это зависело бы от того, насколько удачно были бы подобраны имена.
Здравствуйте, slavo, Вы писали:
LMA>>Как Вам уже писали Выше, Вам следовало бы предложить свой вариант.
S>мой вариант — отдебажить код, а не городить заплатки
Я не вижу в Ваших сообщениях причин считать, что это — заплатка. Возможно, это действительно так. Как Вам уже тут написали, такой код в зависимости от контекста может быть нормальным, а может быть ужасным. Вы не привели достаточно информации, чтобы можно было сделать однозначный вывод.
Здравствуйте, slavo, Вы писали:
S>Если бы я узнал, что такой нормальный код присутствует в ПО самолетов, то испугался бы летать.
От хорошей жизни люди такие проверки в свой код не вставляют. Возникает вопрос — что заставило его вставлять в свой код такие проверки? Т.е. интересно не почему он реализовал проверку именно так, а почему ему вообще пришлось реализовывать проверку такого рода.
Здравствуйте, LordMAD, Вы писали:
LMA>Здравствуйте, ancient, Вы писали:
A>>Уже через полгода даже сам автор обычно не может вспомнить, что же это за "знакомые каждому" константы. LMA>Ты путаешь общий случай и конкретный, который является исключением для общего.
Это как раз ты передергиваешь, и уже сам запутался, по причине ошибочного мнения.
A>>А если константа используется неоднократно по коду? LMA>А имя её будет в этом случае использоваться сколько раз? Ещё раз повторю: значение данной константы говорит больше, чем любое придуманное для нее имя — вот в чем дело.
Вот это вообще чушь, что такое 50 ? а что такое 110 ?
а если это FULL_TANK_LANCER6, FULL_TANK_HUMMER2, короче ты опять в пролете
A>>А если ее потом поменять захочется? (К примеру, MS вдруг захочет в новой версии компилятора другим значением стек заполнять) LMA>А если имя константы поменять захочется?
Опять ты в пролете, при нормальном имени константы почти всегда уникально, поэтому если ты можешь пользоваться replace проблем 0
в отличии от значения константы которое может означать как 60 секунд, так и 60 литров
A>>Кстати, ты число "пи" тоже в программах циферками пишешь? LMA>Число "Пи" известно как число "Пи". А число 0xfdfdfdfd известно как число 0xfdfdfdfd.
Число пи, это число пи, блин ты юморист, а число FULL_TANK_LANCER6 это FULL_TANK_LANCER6, тебя такой ответ устраивает?
Это твоя же логика, причем в контексте программы, последняя константа, может иметь гораздо большую применимость.
A>>А сделай их именованными константами (отл., хор., и т.д.), и неожиданно обнаружишь, что программу практически не надо менять, чтобы учесть в ней американскую систему оценок. LMA>Чушь полная, ибо однозначного соответствия между системами оценок все равно не будет. Такое лишь уменьшит читабельность программы в надежде, что такое когда-нибудь понадобится. Когда выяснится, что нужно на самом деле (а не голословно в надежде, что другого ничего менять не придется), нужно будет просто сделать рефакторинг.
Ну неужели у тебя так все запущено. Начнем с начала, откуда ты знаешь что соответствия не будет?, если измениться только система мер
а логика останется прежней все в порядке, это подтверждается практикой. Представь себе если бы при смене разрешения у игры ее надо было бы
перекомпилировать или в случае пользователя переустанавливать, а в магазинах лежали игры ( CallOfDuty 1024x768, CallOfDuty 1280x800 )
было был наверно здорово, но к счастью такие вот "замечательные" как ты программисты либо там не работают, либо пишут себе маленькие и глупенькие
штучки. И конечно читабельность я уже привел пример выше только возрастает. А про рефакториг ( странно что ты знаешь это слово ).
LMA>>>В данном конкретном случае использование именованных констант привело бы к запутыванию, а не улучшению читабельности (при работе с дампами памяти эти константы обычно не заменяются на имена, поэтому узнаются программистами сходу). A>>В промышленном программировании нет "данных конкретных случаев". Есть общие подходы, которые просто тупо работают, независимо от случая. Например, правило, что _все_ (то есть абсолютно все) константы в программе надо именовать. Тот, кому придется за тобой поддерживать твой код, меньше всего захочет разбираться в твоих персональных "конкретных случаях".
LMA>Общих правил без исключений как раз нет; есть люди, у которых есть большие комплексы, потому что в свое время их больно били по рукам, когда они использовали "не то", "не там" и "не тогда". Нарушение таких правил — это нормально; не нормально — это когда человек нарушает такие правила, не понимая того, какие правила он нарушает и к чему это приведет. LMA>Обрати внимание, сколько человек по данному коду сразу поняли в этой ветке о каких значениях идет речь, а если бы вместо значений стояли бы именованные константы — то это зависело бы от того, насколько удачно были бы подобраны имена.
Есть правила без исключений, про это никто не спорит, но ведь у тебя все на оборот, то что ты пишешь : LMA>не нормально — это когда человек нарушает такие правила, не понимая того, какие правила он нарушает и к чему это приведет.
это тоже не правильно, хотя может звучит интересно, в случае когда человек понимает что он нарушает,
но тем не менее продолжает это делать, как правило исходит от лени писать красивый читабельный код.
У нас в фирме достаточно таких примеров, которые знают но продолжают писать "тошниловку", второй случай
это банальная программерская безграмотность, меня она меньше раздражает, т/к как правило у программистов к этому времени
нет столько амбиций как у тебя, и по первому замечанию пишут более вдумчиво.
LMA>а если бы вместо значений стояли бы именованные константы — то это зависело бы от того, насколько удачно были бы подобраны имена
Здесь форум и примеры здесь естественно должны приводится вместе с константами для точности, и естественно полагать эти константы
увидеть в живом примере, и как можно это приводить как довод? иначе как бред, сказать не могу.
_кодом, то это плохой код, он какой-то не жизнеутверждающий, из понятных слов в нём есть только плохие — top и error, да и располагается он не в одну строчку.
Здравствуйте, codelord, Вы писали:
A>>>Уже через полгода даже сам автор обычно не может вспомнить, что же это за "знакомые каждому" константы. LMA>>Ты путаешь общий случай и конкретный, который является исключением для общего. C> Это как раз ты передергиваешь, и уже сам запутался, по причине ошибочного мнения.
В чем я передергиваю?
C>Вот это вообще чушь, что такое 50 ? а что такое 110 ? C>а если это FULL_TANK_LANCER6, FULL_TANK_HUMMER2, короче ты опять в пролете
Мы не обсуждаем общий случай именованных констант, мы обсуждаем являются конкретные две константы настолько очевидными, чтобы для них не заводить для них имя, или нет.
Если тебе угодно писать, например, так:
const int empty_sum = 0;
int sum = empty_sum;
while (q()) sum += f();
то это твои проблемы.
C>Опять ты в пролете, при нормальном имени константы почти всегда уникально, поэтому если ты можешь пользоваться replace проблем 0 C>в отличии от значения константы которое может означать как 60 секунд, так и 60 литров
Ты пишешь очевидные вещи, жаль только, что они не относятся к обсуждаемому вопросу — см. выше.
C>Ну неужели у тебя так все запущено. Начнем с начала, откуда ты знаешь что соответствия не будет?, если измениться только система мер
Оттуда, что нет причин считать, что соответствие будет.
Про теоретическую общность и как с ней бороться советую почитать хотя бы у Фаулера в книге по рефакторингу.
C>а логика останется прежней все в порядке, это подтверждается практикой.
Давай пример из практики, когда у тебя константы 0xFDFDFDFD, 0xCCCCCCCC, 0xCDCDCDCD, 0xABABABAB и т.д. под MS менялись или нефига теоретизировать про мир во всем мире.
Еще раз повторю: хватит драться с ветряными мельницами и обсуждать очевидные правила — просто докажи, что это правило применимо в данном конкретном случае.
LMA>>не нормально — это когда человек нарушает такие правила, не понимая того, какие правила он нарушает и к чему это приведет. C>это тоже не правильно, хотя может звучит интересно, в случае когда человек понимает что он нарушает, C>но тем не менее продолжает это делать, как правило исходит от лени писать красивый читабельный код. C>У нас в фирме достаточно таких примеров, которые знают но продолжают писать "тошниловку", второй случай C>это банальная программерская безграмотность, меня она меньше раздражает, т/к как правило у программистов к этому времени C>нет столько амбиций как у тебя, и по первому замечанию пишут более вдумчиво.
Если у тебя в фирме такое болото, это не означает, что так у всех. И это никак не дает тебе право писать "как правило исходит от". Или ты приводи статистику из достоверных источников. Любой идиот может в форуме на основании своего опыта написать "как правило", только это к фактам никакого отношения не имеет, это имеет отношение к мнениям.
Если у тебя есть факты, что автор обсуждаемого в топике кода написал такое именно из безграммотности или лени — пожалуйста выкладывай их, а если нет — статистика по твоей фирме не имеет к этому никакого отношения.
LMA>>а если бы вместо значений стояли бы именованные константы — то это зависело бы от того, насколько удачно были бы подобраны имена C>Здесь форум и примеры здесь естественно должны приводится вместе с константами для точности, и естественно полагать эти константы C>увидеть в живом примере, и как можно это приводить как довод? иначе как бред, сказать не могу.
Здравствуйте, LordMAD, Вы писали:
LMA>Здравствуйте, ancient, Вы писали:
A>>Уже через полгода даже сам автор обычно не может вспомнить, что же это за "знакомые каждому" константы. LMA>Ты путаешь общий случай и конкретный, который является исключением для общего.
Когда каждый сам решает, что попадает в правило, а что в исключение, можно считать, что правила просто не существует. Исключения из правила должны прописываться в самом правиле.
A>>А если константа используется неоднократно по коду? LMA>А имя её будет в этом случае использоваться сколько раз? Ещё раз повторю: значение данной константы говорит больше, чем любое придуманное для нее имя — вот в чем дело.
Оно говорит только тебе и только в конкретном контексте. Вот в чем дело
A>>А если ее потом поменять захочется? (К примеру, MS вдруг захочет в новой версии компилятора другим значением стек заполнять) LMA>А если имя константы поменять захочется?
A>>Кстати, ты число "пи" тоже в программах циферками пишешь? LMA>Число "Пи" известно как число "Пи". А число 0xfdfdfdfd известно как число 0xfdfdfdfd.
A>>А сделай их именованными константами (отл., хор., и т.д.), и неожиданно обнаружишь, что программу практически не надо менять, чтобы учесть в ней американскую систему оценок. LMA>Чушь полная, ибо однозначного соответствия между системами оценок все равно не будет. Такое лишь уменьшит читабельность программы в надежде, что такое когда-нибудь понадобится. Когда выяснится, что нужно на самом деле (а не голословно в надежде, что другого ничего менять не придется), нужно будет просто сделать рефакторинг.
Даже если выяснится, что нужно что-то другое, сделав поиск по слову ты найдешь все места, где как-то закладывался на конкретное значение оценки. Поиск по 2-3-4-5 даст гораздо менее удобный результат.
LMA>>>В данном конкретном случае использование именованных констант привело бы к запутыванию, а не улучшению читабельности (при работе с дампами памяти эти константы обычно не заменяются на имена, поэтому узнаются программистами сходу). A>>В промышленном программировании нет "данных конкретных случаев". Есть общие подходы, которые просто тупо работают, независимо от случая. Например, правило, что _все_ (то есть абсолютно все) константы в программе надо именовать. Тот, кому придется за тобой поддерживать твой код, меньше всего захочет разбираться в твоих персональных "конкретных случаях".
LMA>Общих правил без исключений как раз нет; есть люди, у которых есть большие комплексы, потому что в свое время их больно били по рукам, когда они использовали "не то", "не там" и "не тогда". Нарушение таких правил — это нормально; не нормально — это когда человек нарушает такие правила, не понимая того, какие правила он нарушает и к чему это приведет.
Я там вначале написал про дефективность такой трактовки понятия правила.
LMA>Обрати внимание, сколько человек по данному коду сразу поняли в этой ветке о каких значениях идет речь, а если бы вместо значений стояли бы именованные константы — то это зависело бы от того, насколько удачно были бы подобраны имена.
Все эти люди (ты и я, в том числе) поняли, что это автор имел ввиду по _контексту_. Если бы там не было
ici_error = "stack error"
фиг бы мы чего поняли А с правильно подобранным именованием констант можно было бы понять и без этой строчки.
Здравствуйте, slavo, Вы писали:
S>Если бы я узнал, что такой нормальный код присутствует в ПО самолетов, то испугался бы летать.
Оффтоп, конечно, но знал бы ты какой код присутсвует в ПО наших подводных лодок... В том числе с ядерным оружием на борту. По сравнению с ним этот код — просто образец стиля и надёжности.
А по сабжу:
1) Если это человек написал в процессе отлова хитрого бага — вообще не вижу криминала. Я при поиске багов, а особенно чужих багов в малознакомом коде, и не такое могу написать.
2) Если код противоречит официальному codestyle — то причисать.
3) Если код рабочий и предназначен для релиза — он должен быть обложен тестами, и тогда все платформозависимые вещи вылезут сами. И если код не будет работать под какую-то платформу — не коммитить в резиз, пока не заработает, только и всего.
4) Расслабиться Работать в атмосфере явного негатива затруднительно не только данному товарищу, но и остальным коллегам. А вообще, имхо, увольнять человека следует в единственном случае — если он неоднократно мешает работать другим, для остальных провинностей вполне подойдут менее жёсткие меры воздействия.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, ancient, Вы писали:
LMA>>Ты путаешь общий случай и конкретный, который является исключением для общего.
A>Когда каждый сам решает, что попадает в правило, а что в исключение, можно считать, что правила просто не существует. Исключения из правила должны прописываться в самом правиле.
Я знаю только одно правило без исключений — закон подлости. ВСЕ остальные правила имеют исключения.
A>Оно говорит только тебе и только в конкретном контексте. Вот в чем дело
Прочти эту ветку с начала, прежде чем, так говорить. Особенно обрати внимание — сколько человек тут написало, про то, что это будет работать только в debug. Так что не все так плохо с пониманием у людей — не суди по себе.
A>Даже если выяснится, что нужно что-то другое, сделав поиск по слову ты найдешь все места, где как-то закладывался на конкретное значение оценки. Поиск по 2-3-4-5 даст гораздо менее удобный результат.
За любые исправления, основанные на поиске по вхождению, убивать сразу и на месте. Переосмысление и рефакторинг — только так!
A>Я там вначале написал про дефективность такой трактовки понятия правила.
Приведи пример правила, для которого не бывает исключений на твой взгляд -чтобы было о чем говорить.
LMA>>Обрати внимание, сколько человек по данному коду сразу поняли в этой ветке о каких значениях идет речь, а если бы вместо значений стояли бы именованные константы — то это зависело бы от того, насколько удачно были бы подобраны имена.
A>Все эти люди (ты и я, в том числе) поняли, что это автор имел ввиду по _контексту_. Если бы там не было A>
A>ici_error = "stack error"
A>
Тут и констант этих нет — то есть и нечего понимать.
A>фиг бы мы чего поняли А с правильно подобранным именованием констант можно было бы понять и без этой строчки.
более читабельным, чем оригинал. Просто потому, что эти значения люди, которым они действительно нужны, обычно наблюдают в окне дампа, а тем, кто их не имеет привычки наблюдать в окне дампа, и с именованными константами не поймет о чем тут речь идет, IMHO. А при этом какова вероятность, что в реальной программе будут использованы такие длинные наименования, а не менее информативные, но более короткие? IMHO, большая вероятность.
Здравствуйте, MasterZiv, Вы писали:
MZ>slavo wrote: MZ>*slavo*, так раскройте всё-таки КОНТЕКСТ проблемы. MZ>Что это за код, для чего написан, где работает, и т.п.
много всего писать. Это интерпретатор языка C. Работает на винде и линуксе , в релизе и дебаге.
Здравствуйте, frogkiller, Вы писали:
F>4) Расслабиться Работать в атмосфере явного негатива затруднительно не только данному товарищу, но и остальным коллегам. А вообще, имхо, увольнять человека следует в единственном случае — если он неоднократно мешает работать другим, для остальных провинностей вполне подойдут менее жёсткие меры воздействия.
Ну, в общем, я понял основную идею — если ты помнишь, что означает определенная чиселка в программе и думаешь, что остальные тоже должны ее помнить, то ее не обязательно как-либо именовать Все же попробуй с высоты своего кругозора подумать о несчастных, забывших значения этих супер-нужных супер-констант сразу после того, как они научились пользоваться grind'ом или любой другой утилитой автоматического поиска ошибок обращения к памяти.
Здравствуйте, ancient, Вы писали:
A>Ну, в общем, я понял основную идею — если ты помнишь, что означает определенная чиселка в программе и думаешь, что остальные тоже должны ее помнить, то ее не обязательно как-либо именовать
Я лично только из треда понял, что эти магические числа значат, а до этого не знал. В своё оправдание могу лишь сказать, что я на С/С++ пишу не профессионально и не под Винду.
Кстати, есть мнение что в программе могут встречать только два или числовых значения, типа 0, 1 или -1 (вообщем, значения которые многие ф-ции возвращают в случае ошибки), а все остальные числа должны быть за'define'нены. Я лично с этим согласен и всегда придерживаюсь этого стиля.
Здравствуйте, ancient, Вы писали:
A>Ну, в общем, я понял основную идею — если ты помнишь, что означает определенная чиселка в программе и думаешь, что остальные тоже должны ее помнить, то ее не обязательно как-либо именовать Все же попробуй с высоты своего кругозора подумать о несчастных, забывших значения этих супер-нужных супер-констант сразу после того, как они научились пользоваться grind'ом или любой другой утилитой автоматического поиска ошибок обращения к памяти.
Нефига ты не понял! Представь себе, что есть два человека — Вася (В) и Петя (П). Для В понятнее запись 0xcccccccc (а видя UNINITIALIZED_STACK_MEMORY_UNDER_MS_CPP_DEBUGGING_RUNTIME_LIBRARY он подумает "это 0xcccccccc что ли?"), а для П — не понятно ни 0xcccccccc, ни UNINITIALIZED_STACK_MEMORY_UNDER_MS_CPP_DEBUGGING_RUNTIME_LIBRARY. И какой смысл в такой ситуации писать в коде UNINITIALIZED_STACK_MEMORY_UNDER_MS_CPP_DEBUGGING_RUNTIME_LIBRARY? Чтобы всем было одинаково плохо?
ВСЕ остальные правила имеют исключения.
