Здравствуйте, slavo, Вы писали:
S>Что делать с сотрудником, который написал такой код?
Выделить человека, который покажет автору, как код такого стиле надо писать правильно. Показывать личным примером, обучать, обучать и еще раз обучать. Ну а если такого сотрудника приняли на должность сеньера, а не джуниора, то наказать того, кто принимал сотрудника.
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, slavo, Вы писали:
S>>Что делать с сотрудником, который написал такой код? E>Выделить человека, который покажет автору, как код такого стиле надо писать правильно. Показывать личным примером, обучать, обучать и еще раз обучать. Ну а если такого сотрудника приняли на должность сеньера, а не джуниора, то наказать того, кто принимал сотрудника.
Здравствуйте, elmal, Вы писали:
S>>Что делать с сотрудником, который написал такой код? E>Выделить человека, который покажет автору, как код такого стиле надо писать правильно. Показывать личным примером, обучать, обучать и еще раз обучать. Ну а если такого сотрудника приняли на должность сеньера, а не джуниора, то наказать того, кто принимал сотрудника.
А как наказывать? Подзатыльник? Десять палок?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Vain, Вы писали:
S>>>Что делать с сотрудником, который написал такой код? E>>Выделить человека, который покажет автору, как код такого стиле надо писать правильно. Показывать личным примером, обучать, обучать и еще раз обучать. Ну а если такого сотрудника приняли на должность сеньера, а не джуниора, то наказать того, кто принимал сотрудника. V>А как наказывать? Подзатыльник? Десять палок?
Возможно я слишком испорчен. Но 10 палок это чересчур строгое наказание.
Здравствуйте, slavo, Вы писали:
S>Что делать с сотрудником, который написал такой код?
Смотря в каком контексте, если, к примеру, operator [] был перегружен, а код для драйвера какого-либо контроллера, то непонятно.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, slavo, Вы писали:
S>Он далеко не юниор.
Если в общем квалификация приличная (то есть знает кучу технических мелочей, ошибое детских не допускает и код работает нормально, но вот со стилем у него не сложилось, так как не били по рукам в свое время), то просто заставить писать в нужном нормальном стиле, ну и дать почитать соответствующую литературу. Если бить по рукам, то стиль выправляется достаточно быстро. Соответственно ничего страшного.
Хуже если это твой начальник, повышать квалификацию не желает и критики не переносит, так как считает себя мегакрутым, заставить его никак нельзя ничего делать, а все неприятности в проекте именно из-за его кода . В этом случае рано или поздно таких увольняют, правда это может наступить лет через 5, когда уволятся все вменяемые подчиненные, и до высшего руководства начнет доходить, что что-то не то .
Re: Оцените код
От:
Аноним
Дата:
05.09.08 12:59
Оценка:
Здравствуйте, slavo, Вы писали:
S>Что делать с сотрудником, который написал такой код? S>
Хмм, вот тут все так ругают, нет, конечно код выглядит не очень(Для С++!!!), но:
1. Возможно это был первый сабмит человека в данной позиции
2. Контекст вынуждает к такому стилю, и так как он делает переход на fail — то метка уже должна существовать, равно как и логика использующая ici_error для, возможно, возврата кода ошибки, а значит уже какой-то программист с кучерявыми руками создал механизм возврата через коды и goto.
Что касается магических значений — то эти для меня ясны с первого взгляда, и причина такой проверки тоже, и при наличии хотябы комментов к данному коду я бы не придерался.
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, slavo, Вы писали:
S>>Он далеко не юниор. E>Если в общем квалификация приличная (то есть знает кучу технических мелочей, ошибое детских не допускает и код работает нормально, но вот со стилем у него не сложилось, так как не били по рукам в свое время), то просто заставить писать в нужном нормальном стиле, ну и дать почитать соответствующую литературу. Если бить по рукам, то стиль выправляется достаточно быстро. Соответственно ничего страшного.
E>Хуже если это твой начальник, повышать квалификацию не желает и критики не переносит, так как считает себя мегакрутым, заставить его никак нельзя ничего делать, а все неприятности в проекте именно из-за его кода . В этом случае рано или поздно таких увольняют, правда это может наступить лет через 5, когда уволятся все вменяемые подчиненные, и до высшего руководства начнет доходить, что что-то не то .
SI>Антипаттерны: SI>- магические числа SI>- платформозависимость SI>- использование goto SI>- (если код С++) — использование C-style cast
SI>Какой же он после этого не junior? SI>че то вы темните
AG>Если я правильно понял мэджики, то это будет работать только под отладчиком. AG>Поэтому в релиз код не пойдёт. А в целях отладки и не такое напишешь.
на сколько я понял, этот код как раз и был написан, чтобы предотвратить проблемы в релизах, в работающем коде Причем работать это дожно и под вендой, и под линуксом.
Нельзя судить о человеке по одному коммиту.
Если человек вменяем, то легко пожурить и сказать что так лучше не делать.
Если человек вменяем, но не понимает что это будет работать только в debug, то объяснить ему.
Если человек не вменяем, то уволить.
sch>Нельзя судить о человеке по одному коммиту. sch>Если человек вменяем, то легко пожурить и сказать что так лучше не делать. sch>Если человек вменяем, но не понимает что это будет работать только в debug, то объяснить ему. sch>Если человек не вменяем, то уволить.
Злые какие все, а?
В раннем студенчестве я тоже подобный по осмысленности код нередко писал... а хто никогда не писал такого, пусть кинет камень
А вы — уволить, уволить
Не вижу в коде НИЧЕГО криминального. Я понятия не имею, для какого компилятора и среды это написано, и знаю, что есть много примеров, когда использование goto и подобного способа хранить данные в стеке вполне оправдано.
ну и что, что написал?
если это только для отладки, то и сам так сделал бы.
вообщем если код будет компилиться только в отладочной версии и только под винду, то нормально (ну разве что выделить это в макрос/ф-цию, не размножать его по проекту), ну а в релиз такое попадать не должно. Так что сначала скажите какие требования перед товарищем поставили, а уже потом думать можно "что делать"
Здравствуйте, StevenIvanov, Вы писали:
SI>Антипаттерны: SI>- магические числа
Эти значения программистами узнаются лучше, чем какие-то имена для них.
SI>- платформозависимость SI>- использование goto SI>- (если код С++) — использование C-style cast
Сами такие антипаттерны придумали или подсказал кто?
У меня создается впечатление, что Вы просто не знаете что это за константы и от этого начинаете злится на сотрудника.
Собственно не понятно, что именно Вам не нравится в этом коде (например, если весь проект усыпан кодом, который так и так не под MS работать не будет, то почему бы и нет).
Как Вам уже писали Выше, Вам следовало бы предложить свой вариант.
Здравствуйте, sch, Вы писали:
sch>Если человек вменяем, но не понимает что это будет работать только в debug, то объяснить ему.
Проверять срыв стека в release ? Наверное, такое может встретиться либо в чем-то очень экзотичном, либо если это защита от взлома (тогда учитывая примое использование таких констант — плохая защита от взлома). Да и не стал бы автор топика писать тут этот код в таком случае...
Здравствуйте, Corvin, Вы писали:
C>Здравствуйте, Corvin, Вы писали:
C>>Здравствуйте, slavo, Вы писали:
S>>>Что делать с сотрудником, который написал такой код? S>>>
LordMAD wrote:
> У меня создается впечатление, что Вы просто не знаете что это за > константы и от этого начинаете злится на сотрудника. > > Собственно не понятно, что именно Вам не нравится в этом коде (например, > если весь проект усыпан кодом, который так и так не под MS работать не > будет, то почему бы и нет).
Присоединяюсь к недоумению.
без сомнения, нужен контекст.
Все т.н. "антипаттерны", приведённые в топике -- полная ерунда.
Всё зависит от обстоятельств.
Здравствуйте, LordMAD, Вы писали:
LMA>Здравствуйте, StevenIvanov, Вы писали:
SI>>Антипаттерны: SI>>- магические числа
LMA>Эти значения программистами узнаются лучше, чем какие-то имена для них.
SI>>- платформозависимость SI>>- использование goto SI>>- (если код С++) — использование C-style cast
LMA>Сами такие антипаттерны придумали или подсказал кто?
А для вас антипаттенны существуют только в книжках?
По определению:
A design pattern is a "solution to a problem in context"
В случае антипаттернов имеем то же самое — "антирешение" проблемы в некотором контексте.
Если данный код не отладочный и внесен в релиз (в противном случае обсуждение кода лишено смысла) такое решение свидетельствует о крайне непрофессиональном подходе.
Здравствуйте, StevenIvanov, Вы писали:
SI>>>Антипаттерны: SI>>>- магические числа
LMA>>Эти значения программистами узнаются лучше, чем какие-то имена для них.
SI>>>- платформозависимость SI>>>- использование goto SI>>>- (если код С++) — использование C-style cast
LMA>>Сами такие антипаттерны придумали или подсказал кто?
SI>А для вас антипаттенны существуют только в книжках?
SI>По определению:
SI>
SI>A design pattern is a "solution to a problem in context"
SI>В случае антипаттернов имеем то же самое — "антирешение" проблемы в некотором контексте.
SI>Если данный код не отладочный и внесен в релиз (в противном случае обсуждение кода лишено смысла) такое решение свидетельствует о крайне непрофессиональном подходе.
Что касается первого из приведенных Вами антипаттернов, то тут мы имеем дело с величинами, знакомыми каждому, поэтому нет смысла использовать именованные константы. Не надо доводить дело до абсурда: если переменная содержит оценку по математике, то не надо заводить именованные константы для 2, 3, 4 и 5 — и так всем понятно — что есть что. В данном конкретном случае использование именованных констант привело бы к запутыванию, а не улучшению читабельности (при работе с дампами памяти эти константы обычно не заменяются на имена, поэтому узнаются программистами сходу).
Что касается остальных "антипаттернов", то они вовсе не являются антипаттернами. Это нормально: писать платформозависимый код (не нормально как раз тратить ресурсы на написание платформонезависимого кода "про запас"; было бы очень интересно увидеть, как бы Вы написали платформонезависимую проверку на срыв стека — в данном случае имеет место нечто похожее именно на это, IMHO); использовать goto в низкоуровневом коде; использовать C-style cast в коде на C++, если повсеместно в проекте используется старый код на C.
Другими словами, перечисленные вами 3 "антипаттерна", мягко говоря, не являются общепризнанными антипаттернами. Тот же goto наличествует в современных языках не потому, что авторы этих языков — дураки, а потому, что есть случаи, когда goto — то, что надо, несмотря на то, что такие случае редки. И пока автор топика не приведет свой вариант кода, который на его взгляд будет более элегантен, нет причин считать, что данный код плох.
Здравствуйте, LordMAD, Вы писали:
LMA>... SI>>В случае антипаттернов имеем то же самое — "антирешение" проблемы в некотором контексте.
SI>>Если данный код не отладочный и внесен в релиз (в противном случае обсуждение кода лишено смысла) такое решение свидетельствует о крайне непрофессиональном подходе.
LMA>Что касается первого из приведенных Вами антипаттернов, то тут мы имеем дело с величинами, знакомыми каждому, поэтому нет смысла использовать именованные константы. Не надо доводить дело до абсурда...
Вот мне эти величины ни о чем не говорят. Хоть и программирую на С/C++ вот почти уже 5 лет (в основном linux+gcc). И печальный опыт сопровеждения проектов в которых есть такие места тоже есть
Опять же — нет проблем если написано "для себя", на минутку, но если выкладывать такое в качестве финального варианта...
LMA>Что касается остальных "антипаттернов", то они вовсе не являются антипаттернами. Это нормально: писать платформозависимый код (не нормально как раз тратить ресурсы на написание платформонезависимого кода "про запас"; было бы очень интересно увидеть, как бы Вы написали платформонезависимую проверку на срыв стека — в данном случае имеет место нечто похожее именно на это, IMHO); использовать goto в низкоуровневом коде; использовать C-style cast в коде на C++, если повсеместно в проекте используется старый код на C.
Безусловно это нормально. Когда это имеет смысл. Однако, скажем так, не всегда удобно иметь дело с кодом, в котором россыпью "int8, uint32, int16" и на другой платформе компилятор плюется пачками ворнингов.
LMA>Другими словами, перечисленные вами 3 "антипаттерна", мягко говоря, не являются общепризнанными антипаттернами. Тот же goto наличествует в современных языках не потому, что авторы этих языков — дураки, а потому, что есть случаи, когда goto — то, что надо, несмотря на то, что такие случае редки. И пока автор топика не приведет свой вариант кода, который на его взгляд будет более элегантен, нет причин считать, что данный код плох.
По поводу goto — нет проблем, если код на С. Да еще если код-стайл требует оформления в стиле single entry-single exit. В случае с С++ такой код выглядит несколько неопрятно. Как правило в С++ных программах goto встречается в километровых функциях, что так же "антипаттерн". Хотя может быть и кому-то нравится сопровождать такой код
Хотя касаемо топика судить довольно сложно, т.к. не ясен контекст кода.
Нормальный код. Единственное, нужно магические числа задефайнить и скобки поставить
*((int*)ici_os.a_top[-1]).
Не было сказано на каком языке эта программа. Если на С, то проблем вообще нет. Это для С нормально.
Ну и добавить немного коментов.
p.s. люди, которые сразу кидаются увольнять таких сотрудников или сильно бить палками — реально неадекватны.
Здравствуйте, StevenIvanov, Вы писали:
SI>Вот мне эти величины ни о чем не говорят. Хоть и программирую на С/C++ вот почти уже 5 лет (в основном linux+gcc). И печальный опыт сопровеждения проектов в которых есть такие места тоже есть
Код явно специфичен для MS. Плохо это или хорошо — зависит от проекта. Никаких антипаттернов тут быть не может.
SI>Опять же — нет проблем если написано "для себя", на минутку, но если выкладывать такое в качестве финального варианта...
Не любой код может быть написан с поддержкой нескольких платформ. Может ли так быть написан этот код — вопрос остается открытым.
LMA>>Что касается остальных "антипаттернов", то они вовсе не являются антипаттернами. Это нормально: писать платформозависимый код (не нормально как раз тратить ресурсы на написание платформонезависимого кода "про запас"; было бы очень интересно увидеть, как бы Вы написали платформонезависимую проверку на срыв стека — в данном случае имеет место нечто похожее именно на это, IMHO); использовать goto в низкоуровневом коде; использовать C-style cast в коде на C++, если повсеместно в проекте используется старый код на C.
SI>Безусловно это нормально. Когда это имеет смысл. Однако, скажем так, не всегда удобно иметь дело с кодом, в котором россыпью "int8, uint32, int16" и на другой платформе компилятор плюется пачками ворнингов.
Всё на свете должно использоваться только когда оно имеет смысл. А еще — лучше быть здоровым и богатым, чем бедным и больным. Только какое это имеет отношение к приведенным Вами антипаттернам и данному топику?
SI>По поводу goto — нет проблем, если код на С. Да еще если код-стайл требует оформления в стиле single entry-single exit. В случае с С++ такой код выглядит несколько неопрятно.
По-вашему низкоуровневый код на C++ не пишут?
SI>Как правило в С++ных программах goto встречается в километровых функциях, что так же "антипаттерн". Хотя может быть и кому-то нравится сопровождать такой код
Если Вы считаете, что раз Вам встречается "как правило" код "с душком", то это не значит, что у всех так.
SI>Хотя касаемо топика судить довольно сложно, т.к. не ясен контекст кода.
Ну и смысл тогда разбрасываться модными словечками вроде "антипаттерн"? В надежде, что даже сломанные часы дважды в сутки показывают правильно время?
Здравствуйте, LordMAD, Вы писали:
LMA>Что касается первого из приведенных Вами антипаттернов, то тут мы имеем дело с величинами, знакомыми каждому, поэтому нет смысла использовать именованные константы.
Уже через полгода даже сам автор обычно не может вспомнить, что же это за "знакомые каждому" константы. А если константа используется неоднократно по коду? А если ее потом поменять захочется? (К примеру, MS вдруг захочет в новой версии компилятора другим значением стек заполнять)
Кстати, ты число "пи" тоже в программах циферками пишешь?
LMA>Не надо доводить дело до абсурда: если переменная содержит оценку по математике, то не надо заводить именованные константы для 2, 3, 4 и 5 — и так всем понятно — что есть что.
А сделай их именованными константами (отл., хор., и т.д.), и неожиданно обнаружишь, что программу практически не надо менять, чтобы учесть в ней американскую систему оценок.
LMA>В данном конкретном случае использование именованных констант привело бы к запутыванию, а не улучшению читабельности (при работе с дампами памяти эти константы обычно не заменяются на имена, поэтому узнаются программистами сходу).
В промышленном программировании нет "данных конкретных случаев". Есть общие подходы, которые просто тупо работают, независимо от случая. Например, правило, что _все_ (то есть абсолютно все) константы в программе надо именовать. Тот, кому придется за тобой поддерживать твой код, меньше всего захочет разбираться в твоих персональных "конкретных случаях".
AG>>Если я правильно понял мэджики, то это будет работать только под отладчиком. AG>>Поэтому в релиз код не пойдёт. А в целях отладки и не такое напишешь.
S>на сколько я понял, этот код как раз и был написан, чтобы предотвратить проблемы в релизах, в работающем коде Причем работать это дожно и под вендой, и под линуксом.
Ну на счёт мэджиков понятно — "слышал звон, да не знает где он", "главное успеть к релизу", ... .
Интересно вот что: почему [-1] ??? Ведь там же что угодно может быть без всяких расстрелов. Или там ДОЛЖНЫ лежать нормальные данные?
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? Чтобы всем было одинаково плохо?
Здравствуйте, LordMAD, Вы писали:
LMA>Здравствуйте, StevenIvanov, Вы писали:
SI>>Вот мне эти величины ни о чем не говорят. Хоть и программирую на С/C++ вот почти уже 5 лет (в основном linux+gcc). И печальный опыт сопровеждения проектов в которых есть такие места тоже есть
LMA>Код явно специфичен для MS. Плохо это или хорошо — зависит от проекта. Никаких антипаттернов тут быть не может.
... LMA>Не любой код может быть написан с поддержкой нескольких платформ. Может ли так быть написан этот код — вопрос остается открытым.
Но если код может быть с минимальными усилиями написан в расчете на портабельность, то почему бы и нет?
LMA>Ну и смысл тогда разбрасываться модными словечками вроде "антипаттерн"? В надежде, что даже сломанные часы дважды в сутки показывают правильно время?
Это не модные словечки. Это вполне себе распространенное явление, когда вместо нормального, сопровождаемого кода рожают километры го.на.
А код прежде всего должен документировать сам себя — умные люди (Кнут) советуют писать именно в таком стиле.
Из таких мелочей складывается вся программа и уже по таким местам можно судить о коде в целом. Слышали наверное — "Дьявол обитает в мелочах".
И, безусловно, лично мне гораздо удобнее прочитать DEBUG_ERROR_MARK чем 0xfdfdfdfd.
Не думаю, что дальнейшая дискуссия имеет смысл, все равно мы друг другу вряд ли докажем обратное.
Здравствуйте, LordMAD, Вы писали:
LMA>Здравствуйте, ancient, Вы писали:
A>>Ну, в общем, я понял основную идею — если ты помнишь, что означает определенная чиселка в программе и думаешь, что остальные тоже должны ее помнить, то ее не обязательно как-либо именовать Все же попробуй с высоты своего кругозора подумать о несчастных, забывших значения этих супер-нужных супер-констант сразу после того, как они научились пользоваться grind'ом или любой другой утилитой автоматического поиска ошибок обращения к памяти.
LMA>Нефига ты не понял! Представь себе, что есть два человека — Вася (В) и Петя (П). Для В понятнее запись 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? Чтобы всем было одинаково плохо?
Последняя попытка Я бы предпочел увидеть что-то типа этого (чисто стилистически, безотносительно логики кода):
Здравствуйте, slavo, Вы писали:
S>много всего писать. Это интерпретатор языка C. Работает на винде и линуксе , в релизе и дебаге.
Мне больше всего "резал" глаза отрицательный индекс [-1]. Теперь, когда стало понятно, что это работа не с системным стеком/кучей, а со "своими" структурами, режет еще больше. Все остальное по сравнению с этим моментом — косметика и легко исправляется. Соответственно, вопрос, кто это придумал? Автор обсуждаемого фрагмента или кто-то другой?
Андрей Ушаков wrote: > Мне больше всего "резал" глаза отрицательный индекс [-1]. Теперь, когда > стало понятно, что это работа не с системным стеком/кучей, а со "своими" > структурами, режет еще больше.
Чем вам это режет глаза отрицательный индекс массива ?
В определённой ситуации — вполне нормально.
Оно конечно, я бы так не делал, но язык вовсе не запрещает.
Так это адреса в вашей виртуальной машине или в реальном адресном пространстве
задачи ? Или они совмещены ?
Тут очень разные варианты могут быть, может быть для этого вашего интерпретатора
это вообще как число Pi — две всемирные константы.
LordMAD wrote:
> Нефига ты не понял! Представь себе, что есть два человека — Вася (В) и > Петя (П). Для В понятнее запись 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? Чтобы > всем было одинаково плохо?
я вот долго колебался, задавать ли мне вопрос. Но теперь
просто напишу, чтобы не говорили, что человека-Пети не бывает.
Я — Петя. Нет, зовут меня по-другому, но я не понимаю ни того, ни другого.
Здравствуйте, StevenIvanov, Вы писали:
SI>Но если код может быть с минимальными усилиями написан в расчете на портабельность, то почему бы и нет?
Безусловно, с этим никто не спорит.
LMA>>Ну и смысл тогда разбрасываться модными словечками вроде "антипаттерн"? В надежде, что даже сломанные часы дважды в сутки показывают правильно время?
SI>Это не модные словечки. Это вполне себе распространенное явление, когда вместо нормального, сопровождаемого кода рожают километры го.на. SI>А код прежде всего должен документировать сам себя — умные люди (Кнут) советуют писать именно в таком стиле. SI>Из таких мелочей складывается вся программа и уже по таким местам можно судить о коде в целом. Слышали наверное — "Дьявол обитает в мелочах".
Тоже очевидный факт. Только если какие-то стили бывают применимы к некоторым видам проектов, при чем тут антипаттерны? Вам будет легче, если будет существовать антипаттерн "использование goto" (потому что это имеет смысл в определенных проектах) и антипаттерн "не использование goto" (потому что это тоже имеет смысл для других проектов)? Антипаттернами называют откровенно плохие решения, а не решения, которые инода бывают полезными, а иногда — вредными.
SI>И, безусловно, лично мне гораздо удобнее прочитать DEBUG_ERROR_MARK чем 0xfdfdfdfd.
Я нахожу имя DEBUG_ERROR_MARK крайне плохим с точки зрения самодокументирования для константы 0xfdfdfdfd.
Здравствуйте, ancient, Вы писали:
A>Последняя попытка Я бы предпочел увидеть что-то типа этого (чисто стилистически, безотносительно логики кода):
A>
A>#if defined(_WIN32) && defined(_DEBUG)
A>if((int)ici_os.a_top[-1] == MSVC_CRT_MAGIC_UNINITIALIZED_HEAP || *(int*)ici_os.a_top[-1] == MSVC_CRT_MAGIC_UNINITIALIZED_STACK))
A>{
A> ici_error = "stack error";
A> goto fail;
A>}
A>#endif
A>
Я вижу, что ты даже не понимаешь разницы между UNINITIALIZED_STACK_MEMORY и UNINITIALIZED_STACK или между GUARD_BYTES_BEFORE_AND_AFTER_ALLOCATED_HEAP_MEMORY и UNINITIALIZED_HEAP. Остальные отличия — косметика, а учитывая уточнения автора топика по поводу контекста: #if defined(_WIN32) && defined(_DEBUG) — тут явно лишний. Это только доказывает, что имена для констант тебе не помогают понять о чем тут речь и тебя просто следует держать от такого кода подальше (прав я был, когда о Пете писал).
А по поводу того, что читабельнее и что кто помнит, так скажу просто, что последние 6 с лишним лет для отладки MS не использовал (только прогоняется код через их компилятор, чтобы убедится в совместимости) и, тем не менее, константы не забыл, хотя считаю, что память у меня плохая. Так что про то, что через пол года такое без (само)документирования забывается — чушь это просто, не верь этому — забываются собственные константы, а не такие.
АУ>Мне больше всего "резал" глаза отрицательный индекс [-1]. Теперь, когда стало понятно, что это работа не с системным стеком/кучей, а со "своими" структурами, режет еще больше. Все остальное по сравнению с этим моментом — косметика и легко исправляется.
Ну, да. Если верить Страуструпу, то на некоторых платформах доступ по отрицательному индексу может обломаться из-за какой-нибудь встроенной защиты памяти. Видимо, есть на свете такие архитектуры. Вывод такой — код непереносим, хотя на персоналке в обозримом будущем и настоящем будет работать.
Здравствуйте, LordMAD, Вы писали:
LMA>Здравствуйте, ancient, Вы писали:
A>>Последняя попытка Я бы предпочел увидеть что-то типа этого (чисто стилистически, безотносительно логики кода):
A>>
LMA>Я вижу, что ты даже не понимаешь разницы между UNINITIALIZED_STACK_MEMORY и UNINITIALIZED_STACK или между GUARD_BYTES_BEFORE_AND_AFTER_ALLOCATED_HEAP_MEMORY и UNINITIALIZED_HEAP. Остальные отличия — косметика, а учитывая уточнения автора топика по поводу контекста: #if defined(_WIN32) && defined(_DEBUG) — тут явно лишний. Это только доказывает, что имена для констант тебе не помогают понять о чем тут речь и тебя просто следует держать от такого кода подальше (прав я был, когда о Пете писал).
Ты специально тупишь? Я говорил о стиле, а не о логике этого куска и явно написал об этом в предыдущем сообщении. Разуй глаза.
Говорить о логике кода без знания того, что есть ici_os.a_top бессмысленно. Да и не о том речь была.
Учитывая, кстати, что "#if defined(_WIN32) && defined(_DEBUG)" тут, как ты говоришь, лишний, означает лишь, что константы эти не имеют никакого отношения к их использованию в MSVC, а значит и твое понимание этих констант мимо тазика в этом конкретном куске кода. Они просто означают что-то совсем другое, потому что твое понимание основано на их использовании в MSVC, а тут программа, очевидно, сама определяет логику их использования.
LMA>А по поводу того, что читабельнее и что кто помнит, так скажу просто, что последние 6 с лишним лет для отладки MS не использовал (только прогоняется код через их компилятор, чтобы убедится в совместимости) и, тем не менее, константы не забыл, хотя считаю, что память у меня плохая. Так что про то, что через пол года такое без (само)документирования забывается — чушь это просто, не верь этому — забываются собственные константы, а не такие.
Ну, в это трудно поверить и трудно проверить. Я почти уверен, что ты вспомнил об этих константах только когда увидел начальное письмо, и в контексте с "ici_error = "stack error";". Но это не важно, на самом деле, так же как и помнил ли ты их все эти годы или нет.
Здравствуйте, ancient, Вы писали:
A>>>Последняя попытка Я бы предпочел увидеть что-то типа этого (чисто стилистически, безотносительно логики кода):
A>>>
LMA>>Я вижу, что ты даже не понимаешь разницы между UNINITIALIZED_STACK_MEMORY и UNINITIALIZED_STACK или между GUARD_BYTES_BEFORE_AND_AFTER_ALLOCATED_HEAP_MEMORY и UNINITIALIZED_HEAP. Остальные отличия — косметика, а учитывая уточнения автора топика по поводу контекста: #if defined(_WIN32) && defined(_DEBUG) — тут явно лишний. Это только доказывает, что имена для констант тебе не помогают понять о чем тут речь и тебя просто следует держать от такого кода подальше (прав я был, когда о Пете писал).
A>Ты специально тупишь? Я говорил о стиле, а не о логике этого куска и явно написал об этом в предыдущем сообщении. Разуй глаза.
Я и пишу, что твой код отличается только косметическими изменениями и твоим непоминанием того, что делает этот код.
A>Говорить о логике кода без знания того, что есть ici_os.a_top бессмысленно. Да и не о том речь была.
Ошибаешься. Но я рад, что ты признаешь, что использование именованных констант не проясняет для тебя смысл кода.
A>Учитывая, кстати, что "#if defined(_WIN32) && defined(_DEBUG)" тут, как ты говоришь, лишний, означает лишь, что константы эти не имеют никакого отношения к их использованию в MSVC, а значит и твое понимание этих констант мимо тазика в этом конкретном куске кода. Они просто означают что-то совсем другое, потому что твое понимание основано на их использовании в MSVC, а тут программа, очевидно, сама определяет логику их использования.
Опять ошибаешься.
LMA>>А по поводу того, что читабельнее и что кто помнит, так скажу просто, что последние 6 с лишним лет для отладки MS не использовал (только прогоняется код через их компилятор, чтобы убедится в совместимости) и, тем не менее, константы не забыл, хотя считаю, что память у меня плохая. Так что про то, что через пол года такое без (само)документирования забывается — чушь это просто, не верь этому — забываются собственные константы, а не такие.
A>Ну, в это трудно поверить и трудно проверить. Я почти уверен, что ты вспомнил об этих константах только когда увидел начальное письмо, и в контексте с "ici_error = "stack error";". Но это не важно, на самом деле, так же как и помнил ли ты их все эти годы или нет.
Не суди по себе.
Так как ты переходишь на откровенное хамство разговор продолжать дальше смысла не вижу.
LMA>более читабельным, чем оригинал. Просто потому, что эти значения люди, которым они действительно нужны, обычно наблюдают в окне дампа, а тем, кто их не имеет привычки наблюдать в окне дампа, и с именованными константами не поймет о чем тут речь идет, IMHO. А при этом какова вероятность, что в реальной программе будут использованы такие длинные наименования, а не менее информативные, но более короткие? IMHO, большая вероятность.
Здравствуйте, Stormblast, Вы писали:
S>>Здравствуйте, slavo.
S>Чужой код вы выставили на всеобщее обозрение ! S>Так может будите любезны показать теперь свой вариант ? или очкуете ?
во-первых, мне некогда этим заниматься. у меня своя работа. во-вторых, этот код надо убирать и искать сам баг. какой код ты от меня требуешь?
Здравствуйте, ancient, Вы писали:
A>Здравствуйте, LordMAD, Вы писали:
LMA>>Здравствуйте, ancient, Вы писали:
A>>>Ну, в общем, я понял основную идею — если ты помнишь, что означает определенная чиселка в программе и думаешь, что остальные тоже должны ее помнить, то ее не обязательно как-либо именовать Все же попробуй с высоты своего кругозора подумать о несчастных, забывших значения этих супер-нужных супер-констант сразу после того, как они научились пользоваться grind'ом или любой другой утилитой автоматического поиска ошибок обращения к памяти.
LMA>>Нефига ты не понял! Представь себе, что есть два человека — Вася (В) и Петя (П). Для В понятнее запись 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? Чтобы всем было одинаково плохо?
A>Последняя попытка Я бы предпочел увидеть что-то типа этого (чисто стилистически, безотносительно логики кода):
A>
A>#if defined(_WIN32) && defined(_DEBUG)
A>if((int)ici_os.a_top[-1] == MSVC_CRT_MAGIC_UNINITIALIZED_HEAP || *(int*)ici_os.a_top[-1] == MSVC_CRT_MAGIC_UNINITIALIZED_STACK))
A>{
A> ici_error = "stack error";
A> goto fail;
A>}
A>#endif
A>
Здравствуйте, MasterZiv, Вы писали:
MZ>slavo wrote:
>> for (;) >> { >> if ( >> (ici_os.a_top — ici_os.a_base > 0) && >> ((int)ici_os.a_top[-1] == 0xfdfdfdfd || *(int*)ici_os.a_top[-1] == 0xcccccccc))
MZ>Так это адреса в вашей виртуальной машине или в реальном адресном пространстве MZ>задачи ? Или они совмещены ? MZ>Тут очень разные варианты могут быть, может быть для этого вашего интерпретатора MZ>это вообще как число Pi — две всемирные константы.
Здравствуйте, LordMAD, Вы писали:
LMA>Здравствуйте, ancient, Вы писали:
A>>Последняя попытка Я бы предпочел увидеть что-то типа этого (чисто стилистически, безотносительно логики кода):
A>>
LMA>Я вижу, что ты даже не понимаешь разницы между UNINITIALIZED_STACK_MEMORY и UNINITIALIZED_STACK или между GUARD_BYTES_BEFORE_AND_AFTER_ALLOCATED_HEAP_MEMORY и UNINITIALIZED_HEAP. Остальные отличия — косметика, а учитывая уточнения автора топика по поводу контекста: #if defined(_WIN32) && defined(_DEBUG) — тут явно лишний. Это только доказывает, что имена для констант тебе не помогают понять о чем тут речь и тебя просто следует держать от такого кода подальше (прав я был, когда о Пете писал).
LMA>А по поводу того, что читабельнее и что кто помнит, так скажу просто, что последние 6 с лишним лет для отладки MS не использовал (только прогоняется код через их компилятор, чтобы убедится в совместимости) и, тем не менее, константы не забыл, хотя считаю, что память у меня плохая. Так что про то, что через пол года такое без (само)документирования забывается — чушь это просто, не верь этому — забываются собственные константы, а не такие.
имена-дефайны лучше чем константы, потому что они говорят о назначении константы. и любой ламер, увидев это в коде получает больше информации, чем просто 0xfdfdfdfd. И это более документированный код.
Здравствуйте, noodles, Вы писали:
АУ>>Мне больше всего "резал" глаза отрицательный индекс [-1]. Теперь, когда стало понятно, что это работа не с системным стеком/кучей, а со "своими" структурами, режет еще больше. Все остальное по сравнению с этим моментом — косметика и легко исправляется.
N>Ну, да. Если верить Страуструпу, то на некоторых платформах доступ по отрицательному индексу может обломаться из-за какой-нибудь встроенной защиты памяти. Видимо, есть на свете такие архитектуры. Вывод такой — код непереносим, хотя на персоналке в обозримом будущем и настоящем будет работать.
Здравствуйте, slavo, Вы писали:
S>>>Здравствуйте, slavo.
S>>Чужой код вы выставили на всеобщее обозрение ! S>>Так может будите любезны показать теперь свой вариант ? или очкуете ?
S>во-первых, мне некогда этим заниматься. у меня своя работа.
писать по 20 сообщений в "Оцените код" в день
S>во-вторых, этот код надо убирать и искать сам баг.
Как я понимаю, это интерпритатор, и может он так интерпретирует стек выполнения, только сообщение должно быть "использование неиниц. переменной". Без знания задачи можер говорить только о стиле.
S>какой код ты от меня требуешь?
естественно выполняющий теже ф-ии. Казалось бы это очевидно. Многие спрашивают и не получают ответа. Где Ваш код?
Здравствуйте, LordMAD, Вы писали:
LMA>Так как ты переходишь на откровенное хамство разговор продолжать дальше смысла не вижу.
Да ладно, чего не скажешь в пылу спора Ты вон мне, не стесняясь в выражениях, постоянно тыкаешь под нос, что я смысл кода не понимаю, хотя я уже раз пять сказал, что это к обсуждаемой проблеме не имеет никакого отношения
Но если смысл кода действительно важен для осознания истинности этого высказывания:
Что касается первого из приведенных Вами антипаттернов, то тут мы имеем дело с величинами, знакомыми каждому, поэтому нет смысла использовать именованные константы.
То я с удовольствием послушаю твою трактовку того, что этот код делает.
Здравствуйте, slavo, Вы писали:
LMA>>Я нахожу имя DEBUG_ERROR_MARK крайне плохим с точки зрения самодокументирования для константы 0xfdfdfdfd.
S>это хорошее имя. любой ассист его подсветит и покажет реальное значение. а 0xfdfdfdfd — это бардак
Тогда поделитесь какой великой смысл Вы видете за именем DEBUG_ERROR_MARK, кроме абстрактного какой-то-признак-ошибки-для-отладки?
Здравствуйте, slavo, Вы писали:
S>имена-дефайны лучше чем константы, потому что они говорят о назначении константы. и любой ламер, увидев это в коде получает больше информации, чем просто 0xfdfdfdfd. И это более документированный код.
имена-дефайны лучше чем константы, ЕСЛИ они говорят о назначении константы.
Здравствуйте, slavo, Вы писали:
S>во-первых, мне некогда этим заниматься. у меня своя работа. во-вторых, этот код надо убирать и искать сам баг. какой код ты от меня требуешь?
Простите, но Вы батенька позер. Так дела не делаются, покажите уж будьте любезны мастерство рефакторинга, время думаю у вас есть, как тут заметили (писать по 20 постов в день).
Здравствуйте, Stormblast, Вы писали:
S>Здравствуйте, slavo, Вы писали: S>Простите, но Вы батенька позер. Так дела не делаются
Да, да, да.
Судя по скудным односложным ответам slavo, — ему уже давно стало стыдно за создание этой темы.
И ведь ничего конкретного не сказал! Заэпатировал публику и всё...
Здравствуйте, slavo, Вы писали:
S>>Чужой код вы выставили на всеобщее обозрение ! S>>Так может будите любезны показать теперь свой вариант ? или очкуете ?
S>во-первых, мне некогда этим заниматься. у меня своя работа. во-вторых, этот код надо убирать и искать сам баг. какой код ты от меня требуешь?
Баг искать надо. Но и отлавливать ненайденные баги тоже не помешает.
LordMAD wrote:
> лишний. Это только доказывает, что имена для констант тебе не помогают > понять о чем тут речь и тебя просто следует держать от такого кода > подальше (прав я был, когда о Пете писал).
Безусловно, ты был прав.
А можно для "Пети" озвучить, что же означают эти константы ?
Я, в отличие от тебя, в основном, (если работаю с С++) работаю с VC.
Может и пригодится когда.
noodles wrote:
> Ну, да. Если верить Страуструпу, то на некоторых платформах доступ по > отрицательному индексу может обломаться из-за какой-нибудь встроенной > защиты памяти. Видимо, есть на свете такие архитектуры. Вывод такой — > код непереносим, хотя на персоналке в обозримом будущем и настоящем > будет работать.
Чего ? Кто такое сказал-то ?
sometype* base = ...;
base[i];
означает то же, что и
base + i;
Почему же i не может быть отрицательным ?
А будет это работать или нет, зависит целиком от инициализации base.
Никаких правил или ограничений тут быть не может.
1. Константы знакомы только в "том" окошке буковки большие, 0xFDFDFDFD (друг Федя) и 0xCCCCCCCC (муха ЦеЦе) привычнее
2. Опечатка — скобка лишняя справа
3. (int)ici_os.a_top[-1] != 0xfdfdfdfd недостаточно для того, чтобы можно было безопасно * его дальше
>> Ну, да. Если верить Страуструпу, то на некоторых платформах доступ по >> отрицательному индексу может обломаться из-за какой-нибудь встроенной >> защиты памяти. Видимо, есть на свете такие архитектуры.
MZ>Чего ? Кто такое сказал-то ?
Я же написал. The C++ Programming Language, Third Edition, Bjarne Stroustrup. Упоминается такое в паре мест.
MZ>Никаких правил или ограничений тут быть не может.
Могут быть ограничения, реализованные в железе. Например, выделяется массив, а доступ к нему строго ограничивается выделенным куском. Вот, тут отрицательный индекс и обломится. Короче, за деталями к первоисточнику.
Здравствуйте, noodles, Вы писали:
>>> Ну, да. Если верить Страуструпу, то на некоторых платформах доступ по >>> отрицательному индексу может обломаться из-за какой-нибудь встроенной >>> защиты памяти. Видимо, есть на свете такие архитектуры.
MZ>>Чего ? Кто такое сказал-то ?
N>Я же написал. The C++ Programming Language, Third Edition, Bjarne Stroustrup. Упоминается такое в паре мест.
ты бы цитату привел, Старуструп большой
вот пример корректного отрицательного индекса
int a[10];
int *b = &a[1];
int x = b[-1];
это нельзя a[-1]; но по тексту неясно как псе это описано. так что выводы делать рано
Здравствуйте, MasterZiv!
MZ>base[i]; MZ>означает то же, что и MZ>base + i;
Вот что говорит об этом д-р Страуструп (это его ответ Сергею Деревяго):
It is a surprise to most experienced C and C++ programmers that &vc1[200] isn't completely equivalent to vc1+200. In fact, it was a surprise to the C committee also and I expect it to be fixed in the upcoming revision of the standard. (also resolved for C9x — bs 10/13/98)
Так в чем же нарушается эквивалентность? По стандарту C++ мы имеем следующие эквивалентные преобразования:
&vc1[200] -> &(*((vc1)+(200))) -> &*(vc1+200)
Действительно ли равенство &*(vc1+200) == vc1+200 неверно?
Страуструп (там же):
It is false in C89 and C++, but not in K&R C or C9x. The C89 standard simply said that &*(vc1+200) means dereference vc1+200 (which is an error) and then take the address of the result, and the C++ standard copiled the C89 wording. K&R C and C9x say that &* cancels out so that &*(vc1+200) == vc2+200.
Здравствуйте, MasterZiv!
MZ>А можно для "Пети" озвучить, что же означают эти константы ? MZ>Я, в отличие от тебя, в основном, (если работаю с С++) работаю с VC. MZ>Может и пригодится когда. Memory Debug Codes
Microsoft Visual C++ Runtime library 0xFD, 0xFDFDFDFD — No-man's land memory. Extra bytes that belong to the internal block allocated, but not the block you requested. They are placed before and after requested blocks and used for data bound checking.
Compiler initialisations 0xCC, 0xCCCCCCCC — The /GX Microsoft Visual C++ compiler option initialises all local variables not explicitly initialised by the program. It fills all memory used by these variables with 0xCC, 0xCCCCCCCC.
N>>The C++ Programming Language, Third Edition, Bjarne Stroustrup. Упоминается такое в паре мест.
СМ>ты бы цитату привел, Старуструп большой
Стр.92
"Taking a pointer to the element one beyond the end of an array is guaranteed to work. This is
important for many algorithms (§2.7.2, §18.3). However, since such a pointer does not in fact point
to an element of the array, it may not be used for reading or writing. The result of taking the
address of the element before the initial element is undefined and should be avoided. On some
machine architectures, arrays are often allocated on machine addressing boundaries, so ‘‘one before
the initial element’’ simply doesn’t make sense."
Интересно, что это учитывается в реализации обратных итераторов reverse_iterator<Iter>, стр.557.
СМ>это нельзя a[-1]; но по тексту неясно как псе это описано. так что выводы делать рано
Согласен. Делать выводы по тому куску кода скорополительно. Признаю. Но проверять нужно.
Здравствуйте, Сергей Мухин, Вы писали:
СМ>Здравствуйте, slavo, Вы писали:
S>>во-первых, мне некогда этим заниматься. у меня своя работа.
СМ>писать по 20 сообщений в "Оцените код" в день
ты чо, думаешь, что писать в форум и писать код это одно и то же?
S>>во-вторых, этот код надо убирать и искать сам баг. СМ>Как я понимаю, это интерпритатор, и может он так интерпретирует стек выполнения, только сообщение должно быть "использование неиниц. переменной". Без знания задачи можер говорить только о стиле.
S>>какой код ты от меня требуешь? СМ>естественно выполняющий теже ф-ии. Казалось бы это очевидно. Многие спрашивают и не получают ответа. Где Ваш код?
Никакого кода, выполняющего те же функции ты не увидишь, как и любого другого. Если по саюжу тебе больше нечего добвить, как и всем остальным "не получающим ответа", то я не задерживаю. Тема ветки не о моем коде.
Здравствуйте, LordMAD, Вы писали:
LMA>Здравствуйте, slavo, Вы писали:
LMA>>>Я нахожу имя DEBUG_ERROR_MARK крайне плохим с точки зрения самодокументирования для константы 0xfdfdfdfd.
S>>это хорошее имя. любой ассист его подсветит и покажет реальное значение. а 0xfdfdfdfd — это бардак
LMA>Тогда поделитесь какой великой смысл Вы видете за именем DEBUG_ERROR_MARK, кроме абстрактного какой-то-признак-ошибки-для-отладки?
Это имя хорошо уже тем, что оно — имя. И это имя можно поменять. Я не говорю, что DEBUG_ERROR_MARK идеально.
Здравствуйте, LordMAD, Вы писали:
LMA>Здравствуйте, slavo, Вы писали:
S>>имена-дефайны лучше чем константы, потому что они говорят о назначении константы. и любой ламер, увидев это в коде получает больше информации, чем просто 0xfdfdfdfd. И это более документированный код.
LMA>имена-дефайны лучше чем константы, ЕСЛИ они говорят о назначении константы.
Здравствуйте, Stormblast, Вы писали:
S>Здравствуйте, slavo, Вы писали:
S>>во-первых, мне некогда этим заниматься. у меня своя работа. во-вторых, этот код надо убирать и искать сам баг. какой код ты от меня требуешь?
S>Простите, но Вы батенька позер. Так дела не делаются, покажите уж будьте любезны мастерство рефакторинга, время думаю у вас есть, как тут заметили (писать по 20 постов в день).
как я уже оветил, эта тема не о моем коде. Во-вторых, я еще раз, для тех, кто в танке, повторяю, что никакого моего кода, делающего ТО ЖЕ САМОЕ, не будет.
Здравствуйте, noodles, Вы писали:
N>>>The C++ Programming Language, Third Edition, Bjarne Stroustrup. Упоминается такое в паре мест.
СМ>>ты бы цитату привел, Старуструп большой
N>Стр.92
N>"Taking a pointer to the element one beyond the end of an array is guaranteed to work. This is N>important for many algorithms (§2.7.2, §18.3). However, since such a pointer does not in fact point N>to an element of the array, it may not be used for reading or writing. The result of taking the N>address of the element before the initial element is undefined and should be avoided. On some N>machine architectures, arrays are often allocated on machine addressing boundaries, so ‘‘one before N>the initial element’’ simply doesn’t make sense."
Эта цитата говорит об исполдьзовании памяти вне массива. А у нас случай другой. У нас индекс -1, а выходит ли он за границы массив — неизвестно.
Незачет.
N>Интересно, что это учитывается в реализации обратных итераторов reverse_iterator<Iter>, стр.557.
СМ>>это нельзя a[-1]; но по тексту неясно как псе это описано. так что выводы делать рано
N>Согласен. Делать выводы по тому куску кода скорополительно. Признаю. Но проверять нужно.
Здравствуйте, Green Chest, Вы писали:
GC>Здравствуйте, Stormblast, Вы писали:
S>>Здравствуйте, slavo, Вы писали: S>>Простите, но Вы батенька позер. Так дела не делаются
GC>Да, да, да. GC>Судя по скудным односложным ответам slavo, — ему уже давно стало стыдно за создание этой темы. GC>И ведь ничего конкретного не сказал! Заэпатировал публику и всё...
мои односложные ответы говорят как раз о том, что у меня есть работа в отличие от многих тут
ответы я уже получил
Здравствуйте, slavo, Вы писали:
S>>>во-первых, мне некогда этим заниматься. у меня своя работа. во-вторых, этот код надо убирать и искать сам баг. какой код ты от меня требуешь?
S>>Простите, но Вы батенька позер. Так дела не делаются, покажите уж будьте любезны мастерство рефакторинга, время думаю у вас есть, как тут заметили (писать по 20 постов в день).
S>как я уже оветил, эта тема не о моем коде. Во-вторых, я еще раз, для тех, кто в танке, повторяю, что никакого моего кода, делающего ТО ЖЕ САМОЕ, не будет.
спасибо за пряимой ответ.
прежде чем что-то критиковать, хорошо бы знать, что бы ты сделал в данной ситуации. Иначе это не критика, а критиканство.
еще вопрос касается прав на текст.
Кто является собственником данного кода (автор, ты, фирма где работает автор, заказчик)?
и еще вопрос морально-этический: Сообщил ли ты автору текста, что выложил его текст на всеобщее обозрение?
Здравствуйте, Сергей Мухин, Вы писали:
СМ>Здравствуйте, slavo, Вы писали:
S>>>>во-первых, мне некогда этим заниматься. у меня своя работа. во-вторых, этот код надо убирать и искать сам баг. какой код ты от меня требуешь?
S>>>Простите, но Вы батенька позер. Так дела не делаются, покажите уж будьте любезны мастерство рефакторинга, время думаю у вас есть, как тут заметили (писать по 20 постов в день).
S>>как я уже оветил, эта тема не о моем коде. Во-вторых, я еще раз, для тех, кто в танке, повторяю, что никакого моего кода, делающего ТО ЖЕ САМОЕ, не будет.
СМ>спасибо за пряимой ответ.
СМ>прежде чем что-то критиковать, хорошо бы знать, что бы ты сделал в данной ситуации. Иначе это не критика, а критиканство.
СМ>еще вопрос касается прав на текст. СМ>Кто является собственником данного кода (автор, ты, фирма где работает автор, заказчик)?
коммерческая тайна, к сабжу отношения не имеет
СМ>и еще вопрос морально-этический: Сообщил ли ты автору текста, что выложил его текст на всеобщее обозрение?
я выложил только фрагмент, который он сам вероятно скопипастил. Автор не в курсе. А так как чисто авторского там только операция =, то не вижу смысла ставить его в известность. Ему будут предъявлены конкретные претензии и пожелания для исправления.
СМ>>еще вопрос касается прав на текст. СМ>>Кто является собственником данного кода (автор, ты, фирма где работает автор, заказчик)?
S>коммерческая тайна, к сабжу отношения не имеет
это как сказать. Теперь продукт, который создает фирма, в которой Вы работаете может быть отклонен
СМ>>и еще вопрос морально-этический: Сообщил ли ты автору текста, что выложил его текст на всеобщее обозрение?
S>я выложил только фрагмент, который он сам вероятно скопипастил. Автор не в курсе. А так как чисто авторского там только операция =, то не вижу смысла ставить его в известность. Ему будут предъявлены конкретные претензии и пожелания для исправления.
т.е. человек сидит с Вами в одной комнате, или по крайней мере, работает в одном проекте с Вами, Вы его код выставляете на всеобщее обозрение (не имея никакой _своей_ альтернативы этому коду) не ставите его в известность об этом и это Вы считается нормально?
Здравствуйте, Сергей Мухин, Вы писали:
S>>я выложил только фрагмент, который он сам вероятно скопипастил. Автор не в курсе. А так как чисто авторского там только операция =, то не вижу смысла ставить его в известность. Ему будут предъявлены конкретные претензии и пожелания для исправления.
СМ>т.е. человек сидит с Вами в одной комнате, или по крайней мере, работает в одном проекте с Вами, Вы его код выставляете на всеобщее обозрение (не имея никакой _своей_ альтернативы этому коду) не ставите его в известность об этом и это Вы считается нормально?
Это не страшно до тех пор, пока он не называет его имя.
Здравствуйте, alzt, Вы писали:
S>>>я выложил только фрагмент, который он сам вероятно скопипастил. Автор не в курсе. А так как чисто авторского там только операция =, то не вижу смысла ставить его в известность. Ему будут предъявлены конкретные претензии и пожелания для исправления.
СМ>>т.е. человек сидит с Вами в одной комнате, или по крайней мере, работает в одном проекте с Вами, Вы его код выставляете на всеобщее обозрение (не имея никакой _своей_ альтернативы этому коду) не ставите его в известность об этом и это Вы считается нормально?
A>Это не страшно до тех пор, пока он не называет его имя.
SergeCpp wrote:
> MZ>А можно для "Пети" озвучить, что же означают эти константы ? > MZ>Я, в отличие от тебя, в основном, (если работаю с С++) работаю с VC. > MZ>Может и пригодится когда. > *Memory Debug Codes <http://docsultant.com/site2/articles/debug_codes.html>*
Здравствуйте, Stormblast, Вы писали:
S>Здравствуйте, slavo, я Вас умоляю не пишите больше ни когда. Единственно, кого жалко так, это ваших подчиненных.
SergeCpp wrote: > MZ>base[i]; > MZ>означает то же, что и > MZ>base + i; > > Вот что говорит об этом д-р Страуструп (это его ответ Сергею Деревяго
На самом деле я бы мог этого не писать, не приводить этой эквивалентности.
От этого ничего бы не изменилось.
> It is false in C89 and C++, but not in K&R C or C9x. The C89 > standard simply said that &*(vc1+200) means dereference vc1+200 > (which is an error) and then take the address of the result, and the > C++ standard copiled the C89 wording. K&R C and C9x say that &* > cancels out so that &*(vc1+200) == vc2+200.
Я не понял, почему это "dereference vc1+200 ... is an error".
И я не понял, почему это они не могут взаимо компенсировать & и *.
Здравствуйте, slavo, Вы писали:
LMA>>Тогда поделитесь какой великой смысл Вы видете за именем DEBUG_ERROR_MARK, кроме абстрактного какой-то-признак-ошибки-для-отладки?
S>Это имя хорошо уже тем, что оно — имя. И это имя можно поменять. Я не говорю, что DEBUG_ERROR_MARK идеально.
Правильно ли я понимаю, что Вы считаете, что имя MAGIC_NUMBER_1 лучше, чем 0xfdfdfdfd ?
Здравствуйте, LordMAD, Вы писали:
LMA>Здравствуйте, slavo, Вы писали:
LMA>>>Тогда поделитесь какой великой смысл Вы видете за именем DEBUG_ERROR_MARK, кроме абстрактного какой-то-признак-ошибки-для-отладки?
S>>Это имя хорошо уже тем, что оно — имя. И это имя можно поменять. Я не говорю, что DEBUG_ERROR_MARK идеально.
LMA>Правильно ли я понимаю, что Вы считаете, что имя MAGIC_NUMBER_1 лучше, чем 0xfdfdfdfd ?
Здравствуйте, slavo, Вы писали:
LMA>>Правильно ли я понимаю, что Вы считаете, что имя MAGIC_NUMBER_1 лучше, чем 0xfdfdfdfd ?
S>не MAGIC_NUMBER_1, а осмысленно имя
В CRT кстати это объявлено как:
static unsigned char _bNoMansLandFill = 0xFD; /* fill no-man's land with this */
Здравствуйте, slavo, Вы писали:
LMA>>>>Тогда поделитесь какой великой смысл Вы видете за именем DEBUG_ERROR_MARK, кроме абстрактного какой-то-признак-ошибки-для-отладки?
S>>>Это имя хорошо уже тем, что оно — имя. И это имя можно поменять. Я не говорю, что DEBUG_ERROR_MARK идеально.
LMA>>Правильно ли я понимаю, что Вы считаете, что имя MAGIC_NUMBER_1 лучше, чем 0xfdfdfdfd ?
S>не MAGIC_NUMBER_1, а осмысленно имя
Я просто хочу понять: где Вы видите ту грань между какой-то-признак-ошибки-для-отладки и магическое-число-1 ? Оба имени ничего полезного, по сути, не сообщают, но первое имя Вам не нравится, а второе — нравится.
Здравствуйте, LordMAD, Вы писали:
LMA>Я просто хочу понять: где Вы видите ту грань между какой-то-признак-ошибки-для-отладки и магическое-число-1 ? Оба имени ничего полезного, по сути, не сообщают, но первое имя Вам не нравится, а второе — нравится.
В смысле одно — нравится, другое — не нравится. Я думаю, Вы поняли какое из них Вам нравится, а какое нет.
Здравствуйте, LordMAD, Вы писали:
LMA>Здравствуйте, slavo, Вы писали:
LMA>>>>>Тогда поделитесь какой великой смысл Вы видете за именем DEBUG_ERROR_MARK, кроме абстрактного какой-то-признак-ошибки-для-отладки?
S>>>>Это имя хорошо уже тем, что оно — имя. И это имя можно поменять. Я не говорю, что DEBUG_ERROR_MARK идеально.
LMA>>>Правильно ли я понимаю, что Вы считаете, что имя MAGIC_NUMBER_1 лучше, чем 0xfdfdfdfd ?
S>>не MAGIC_NUMBER_1, а осмысленно имя
LMA>Я просто хочу понять: где Вы видите ту грань между какой-то-признак-ошибки-для-отладки и магическое-число-1 ? Оба имени ничего полезного, по сути, не сообщают, но первое имя Вам не нравится, а второе — нравится.
имя какой-то-признак-ошибки-для-отладки говорит хоть что-то, имя MAGIC_NUMBER_1 вообще ничего не говорит и может конфликтовать или быть похожим на другое аналогичное имя для другого значения.
Еще аргумент в пользу именования (дефайнами или константами) таких значений — это то, что наткнувшись в коде на подобное имя, можно посмотреть, где оно объявлено и там же, в одном месте на весь проект, прочитать к этому имени подробное описание на человеческом языке.
В мелких проектах это может быть и не так важно, но это очень удобно и правильно, когда над громадным проектом работают десятки людей и часто приходят новые люди, либо разным людям приходится читать чужой код. Если такая культура именования всяких констант и их подробное описание будет соблюдаться, то новичку будет легче соориентироваться в проекте, кроме того, он будет вынужден соблюдать эту культуру и не засорять код магическими числами, чистота кода будет выше. И если кто-то знает о смысле значения, например, 0xfdfdfdfd, то сделав его дефайном или константой, и описав это значение в месте объявления дефайна, он сэкономит очень много времени тем, кто по каким-то причинам еще не знает о смысле этого значения. И тем самым сделает доброе дело своим сотрудникам. И они ему еще спасибо скажут.
Далее, если в какой-то момент вы захотите сменить значение константы, то вы сможете это сделать в одном месте. Даже если это значение всем известное и как-будто бы никогда не меняющееся, может возникнуть необходимость сменить значение ради какого-то эксперимента.
Опять же, в мелких проектах выгода от этого может быть не заметна, но в крупных — это экономия времени и нервов, своих и чужих.
Здравствуйте, carpenter!
SC>>if( (int)ici_os.a_top[-1] == 0xfdfdfdfd || *(int*)ici_os.a_top[-1] == 0xcccccccc ) ) SC>>3. (int)ici_os.a_top[-1] != 0xfdfdfdfd недостаточно для того, чтобы можно было безопасно * его дальше
C> если выполнилось первое условие — второе не проверяется
Здравствуйте, SergeCpp, Вы писали:
SC>Здравствуйте, carpenter!
SC>>>if( (int)ici_os.a_top[-1] == 0xfdfdfdfd || *(int*)ici_os.a_top[-1] == 0xcccccccc ) ) SC>>>3. (int)ici_os.a_top[-1] != 0xfdfdfdfd недостаточно для того, чтобы можно было безопасно * его дальше
C>> если выполнилось первое условие — второе не проверяется
SC>Условимся для простоты: ici_os.a_top[-1] — это z
SC>Тогда имеем: if( (int)z == 0xfdfdfdfd || *(int*)z == 0xcccccccc )
SC>Допустим, что z == 0 (к примеру)
SC>Тогда: первое условие ( (int)z == 0xfdfdfdfd ) не выполняется, проверяется следующее: ( *(int*)z == 0xcccccccc ) или ( *(int*)0 == 0xcccccccc )
Здравствуйте, slavo, Вы писали:
LMA>>Я просто хочу понять: где Вы видите ту грань между какой-то-признак-ошибки-для-отладки и магическое-число-1 ? Оба имени ничего полезного, по сути, не сообщают, но первое имя Вам не нравится, а второе — нравится.
S>имя какой-то-признак-ошибки-для-отладки говорит хоть что-то, имя MAGIC_NUMBER_1 вообще ничего не говорит
А кому нужно имя, которое "говорит хоть что-то"? Вы либо понимаете для чего константа (и в этом случае, можете тестировать, править и т.д. код), либо не понимаете. В последнем случае, Вы будете гарантированно тратить время на то, чтобы разбираться в этом. И Вам такое имя нравится, как Вы писали выше! Вы начали эту ветку с того, что привели пример плохого, как Вам кажется, кода, насколько я понимаю. Вы сами можете видеть по сообщениям в этой ветке, сколько людей сразу поняли назначение констант, и Вы после этого считаете, что имя какой-то-признак-ошибки-для-отладки было бы более понятным вариантом? То есть пусть лучше всем назначение константы будет не понятно (лишь намек в имени такой константы — типа куда копать), чем лишь некоторым оно будет понятно, а другим не понятно и без намеков?
S> и может конфликтовать или быть похожим на другое аналогичное имя для другого значения.
Вы считаете, что имя DEBUG_ERROR_MARK не может конфликтовать или быть похожим на другое имя?
Кстати, интересно, если DEBUG_ERROR_MARK == 0xfdfdfdfd, то какое имя будет для 0xcccccccc ?
S>Еще аргумент в пользу именования (дефайнами или константами) таких значений — это то, что наткнувшись в коде на подобное имя, можно посмотреть, где оно объявлено и там же, в одном месте на весь проект, прочитать к этому имени подробное описание на человеческом языке. S>В мелких проектах это может быть и не так важно, но это очень удобно и правильно, когда над громадным проектом работают десятки людей и часто приходят новые люди, либо разным людям приходится читать чужой код. Если такая культура именования всяких констант и их подробное описание будет соблюдаться, то новичку будет легче соориентироваться в проекте, кроме того, он будет вынужден соблюдать эту культуру и не засорять код магическими числами, чистота кода будет выше. И если кто-то знает о смысле значения, например, 0xfdfdfdfd, то сделав его дефайном или константой, и описав это значение в месте объявления дефайна, он сэкономит очень много времени тем, кто по каким-то причинам еще не знает о смысле этого значения. И тем самым сделает доброе дело своим сотрудникам. И они ему еще спасибо скажут.
Проблема в том, что в данном конкретном случае, именование константы не сделает код читабельнее для всех — оно сделает код читабельнее для одних и менее читабельным для других.
S>Далее, если в какой-то момент вы захотите сменить значение константы, то вы сможете это сделать в одном месте. Даже если это значение всем известное и как-будто бы никогда не меняющееся, может возникнуть необходимость сменить значение ради какого-то эксперимента.
Про то, как Вы планируете сказать MS VS, чтобы оно писало в память не эти константы, а другие, потому что в if Вы будете сравнивать его с другим значением — пожалуйста поподробнее. Ваши доводы, возможно, имели бы смысл, если бы в коде эти значения использовались бы несколько раз.
Здравствуйте, LordMAD, Вы писали:
LMA>То есть пусть лучше всем назначение константы будет не понятно (лишь намек в имени такой константы — типа куда копать), чем лишь некоторым оно будет понятно, а другим не понятно и без намеков?
LMA>Вы считаете, что имя DEBUG_ERROR_MARK не может конфликтовать или быть похожим на другое имя?
LMA>Кстати, интересно, если DEBUG_ERROR_MARK == 0xfdfdfdfd, то какое имя будет для 0xcccccccc ?
LMA>Проблема в том, что в данном конкретном случае, именование константы не сделает код читабельнее для всех — оно сделает код читабельнее для одних и менее читабельным для других.
Дефаны должны быть такими (либо константы):
// The constant 0xccccccccc is used inside MSVS to indicate........
// ...
// ...#define _CCCCCCCC_ 0xcccccccc
// The constant 0xfdfdfdfd is used inside MSVS to indicate........
// ...
// ...#define _FDFDFDFD_ 0xfdfdfdfd
все. это решает и проблему читаемости и позволяет описать значение в одном месте и сменить ради экперимента. На 95% это может и не понадобится, но если понадобится, то будет поздно: S>>Далее, если в какой-то момент вы захотите сменить значение константы, то вы сможете это сделать в одном месте. Даже если это значение всем известное и как-будто бы никогда не меняющееся, может возникнуть необходимость сменить значение ради какого-то эксперимента. LMA>Про то, как Вы планируете сказать MS VS, чтобы оно писало в память не эти константы, а другие, потому что в if Вы будете сравнивать его с другим значением — пожалуйста поподробнее. Ваши доводы, возможно, имели бы смысл, если бы в коде эти значения использовались бы несколько раз.
Читаю вашу переписку и вспоминается отличный анкедот:
Два приятеля обсуждают программирование. Оба сходятся на том, что все константы в коде должны быть именованы и определены где-то во вне. В качестве примера один из них показывает свою недавнюю работу. Второй справшивает
— А что это за const int N_DIMESSION = 2?
— Размерность дисплея...
Здравствуйте, MasterZiv, Вы писали:
MZ>Я не понял, почему это "dereference vc1+200 ... is an error".
Видимо, предполагается
some vc1[200];
MZ>И я не понял, почему это они не могут взаимо компенсировать & и *.
Потому что перегрузка?
Можно было бы компенсировать только если нет перегрузки.
Но что если:
Как я понял автор "подсмотрел" код коллеги, который не является его подчинёным, и спрашивает "Что делать с таким сотрудником".
Извините за вопрос — но что вы можете сделать с сотрудником не являющимся в вашем подчинении? Пойти и постучать его начальнику о том какой тот херовый кодер?
Ещё я также понял что автор кода скопировал его изменив 1 символ — а это означает что код был скопипастен с этого-же проекта.
Кто был изначальным автором данного кода?
Я думаю — вы просто злы на хорошего программиста и таким образом удовлетворяете чувство собственного достоинства. Тк паттерны/антипаттерны это всё становится равным нулю когда проект рушится с треском, я видел десятки проектов написанных по паттернам но кривыми руками, когда погоня в борьбе с антипаттернами приводила к краху, и вы мне напоминаете имено того человека который это всё интегрировал(Cedric Templie)
Здравствуйте, Vamp, Вы писали:
V>Читаю вашу переписку и вспоминается отличный анкедот:
V>
V>Два приятеля обсуждают программирование. Оба сходятся на том, что все константы в коде должны быть именованы и определены где-то во вне. В качестве примера один из них показывает свою недавнюю работу. Второй справшивает
V>- А что это за const int N_DIMESSION = 2?
V>- Размерность дисплея...
Смешно, потому что правда
Предлагаю проголосовать в специально созданном по этой теме голосовании.
Re[19]: Оцените код
От:
Аноним
Дата:
11.09.08 08:54
Оценка:
А вы заметили что минусы в пред постах поставил один свало, он похоже обиделся тут на всех ))
не обижайся свало, ты крутой оценщик кода а главное на все посты ответил железными аргументами ))
Re[20]: Оцените код
От:
Аноним
Дата:
11.09.08 09:19
Оценка:
Здравствуйте, Аноним, Вы писали:
А>А вы заметили что минусы в пред постах поставил один свало, он похоже обиделся тут на всех )) А>не обижайся свало, ты крутой оценщик кода а главное на все посты ответил железными аргументами ))
а ты точно хорошо посмотрел?
Re[21]: Оцените код
От:
Аноним
Дата:
11.09.08 09:29
Оценка:
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Аноним, Вы писали:
А>>А вы заметили что минусы в пред постах поставил один свало, он похоже обиделся тут на всех )) А>>не обижайся свало, ты крутой оценщик кода а главное на все посты ответил железными аргументами ))
А>а ты точно хорошо посмотрел?
Да, всем кто был против него поставил минусы только он. (Может быть и есть где то исключения, я глянул в 15 последних)
Re[2]: Оцените код
От:
Аноним
Дата:
11.09.08 09:33
Оценка:
Здравствуйте, Аноним, Вы писали:
А>Как я понял ... А>Ещё я также понял... А>Я думаю ...
угомони свое воспаленное воображение
отлаживать прострел стека — заоблачный успех
Здравствуйте, Mazay, Вы писали:
M>Ну на счёт мэджиков понятно — "слышал звон, да не знает где он", "главное успеть к релизу", ... . M>Интересно вот что: почему [-1] ??? Ведь там же что угодно может быть без всяких расстрелов. Или там ДОЛЖНЫ лежать нормальные данные?
Ничего ты не понял насчет мейджиков Этими магическими числами студийный компилятор заполняет память ДО выделенного куска, причем только в ДЕБАГЕ. Надеюсь теперь про -1 понятно?
Здравствуйте, LordMAD, Вы писали:
LMA>Здравствуйте, dkon, Вы писали:
D>>Предлагаю проголосовать в специально созданном по этой теме голосовании.
LMA>А чего же не дали возможности свой вариант ответа вводить?
Думал, что постановка вопроса не предполагает вариаций Исправил.
Здравствуйте, dkon, Вы писали:
LMA>>Здравствуйте, dkon, Вы писали:
D>>>Предлагаю проголосовать в специально созданном по этой теме голосовании.
D>Думал, что постановка вопроса не предполагает вариаций Исправил.
вопрос не очень корректный "Является ли строгой необходимостью использование в программах, создаваемых и поддерживаемых усилиями значительного числа людей, именованных сущностей вместо любых константных выражений в исходном коде?"
1. что такое константное выражение?
const float pi = 3 + 0.14;
это pi 3 или 3+0.14
2. Что делать со строками? false/true и тп. т.е. я бы говорил об использовании числовых литералов,
3. обычно 0 и 1 исключают
и уж если придираться, то "значительное число" абсолютно не понятно
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Mazay, Вы писали:
M>>Ну на счёт мэджиков понятно — "слышал звон, да не знает где он", "главное успеть к релизу", ... . M>>Интересно вот что: почему [-1] ??? Ведь там же что угодно может быть без всяких расстрелов. Или там ДОЛЖНЫ лежать нормальные данные? А>Ничего ты не понял насчет мейджиков Этими магическими числами студийный компилятор заполняет память ДО выделенного куска, причем только в ДЕБАГЕ. Надеюсь теперь про -1 понятно?
Непонятно. Почему тогда ici_error = "stack error"; ? Это же должно быть нормальным состоянием. Во-вторых, кто гарантирует, что перед ici_os.a_top ничего нет? Если ici_os — структура, то перед a_top вполне может быть что-то осмысленное. ici_os целиком может лежать сразу за какими-то данными.
Главное гармония ...
Re[6]: Оцените код
От:
Аноним
Дата:
11.09.08 10:37
Оценка:
Здравствуйте, Mazay, Вы писали:
M>>>Ну на счёт мэджиков понятно — "слышал звон, да не знает где он", "главное успеть к релизу", ... . M>>>Интересно вот что: почему [-1] ??? Ведь там же что угодно может быть без всяких расстрелов. Или там ДОЛЖНЫ лежать нормальные данные? А>>Ничего ты не понял насчет мейджиков Этими магическими числами студийный компилятор заполняет память ДО выделенного куска, причем только в ДЕБАГЕ. Надеюсь теперь про -1 понятно? M>Непонятно. Почему тогда ici_error = "stack error"; ? Это же должно быть нормальным состоянием. Во-вторых, кто гарантирует, что перед ici_os.a_top ничего нет? Если ici_os — структура, то перед a_top вполне может быть что-то осмысленное. ici_os целиком может лежать сразу за какими-то данными.
Потому, что http://forum.antichat.ru/showpost.php?p=238561&postcount=7
7. Отладочные значения в различных областях памяти программы
0xCDCDCDCD Память выделена в куче, не инициализирована
0xDDDDDDDD Память, выделенная в куче, уже освобождена
0xFDFDFDFD Заполнитель NoMansLand записывается у границ участка памяти для контроля распространенного типа ошибки выхода за границы массива и переполнения. После затирании это указатели при освобождлении этой памяти free/delete выдаст диалоговое окно: DAMAGE: after ТИП block (#номер) at 0xадрес., где ТИП — обычно Normal — тип освобождаемого участка, номер — номер блока.
P.S. Что с кывтом случилось? 7 страниц флейма, а по делу аноним пишет.
Здравствуйте, dkon, Вы писали:
D>Здравствуйте, LordMAD, Вы писали:
LMA>>Здравствуйте, dkon, Вы писали:
D>>>Предлагаю проголосовать в специально созданном по этой теме голосовании.
LMA>>А чего же не дали возможности свой вариант ответа вводить?
D>Думал, что постановка вопроса не предполагает вариаций Исправил.
Мда... Особенно радуют те, кто голосуют "За, но иногда против" Неужто нельзя придумать константе имя, чтобы бы оно было, по крайней мере, такое же информативное, как значение константы? Давайте хотя бы составим список таких констант Вот начало:
Здравствуйте, ancient, Вы писали:
A>Мда... Особенно радуют те, кто голосуют "За, но иногда против" Неужто нельзя придумать константе имя, чтобы бы оно было, по крайней мере, такое же информативное, как значение константы?
Зачем? Чтобы кода было больше и, соответственно, чтобы было сложнее в нем разбираться?
Я уже писал выше, что любое правило можно довести до полного идиотизма:
const int empty_sum = 0;
int sum = empty_sum;
while (q()) sum += f();
Здравствуйте, LordMAD, Вы писали:
LMA>Здравствуйте, ancient, Вы писали:
A>>Мда... Особенно радуют те, кто голосуют "За, но иногда против" Неужто нельзя придумать константе имя, чтобы бы оно было, по крайней мере, такое же информативное, как значение константы?
LMA>Зачем? Чтобы кода было больше и, соответственно, чтобы было сложнее в нем разбираться?
Как раз для того, чтобы наоборот Это нужно для тех, кто числа такого мог не видеть раньше в таком значении, по разным причинам.
LMA>Я уже писал выше, что любое правило можно довести до полного идиотизма:
А зачем?
LMA>
LMA>const int empty_sum = 0;
LMA>int sum = empty_sum;
LMA>while (q()) sum += f();
LMA>
LMA>Нравится, наверное, код, да?
Против арифметического "0" ничего не имею, эту константу действительно все знают и именно под таким обозначением В отличии от... ну, ты знаешь какого числа
Здравствуйте, ancient, Вы писали:
A>>>Мда... Особенно радуют те, кто голосуют "За, но иногда против" Неужто нельзя придумать константе имя, чтобы бы оно было, по крайней мере, такое же информативное, как значение константы?
LMA>>Зачем? Чтобы кода было больше и, соответственно, чтобы было сложнее в нем разбираться?
A>Как раз для того, чтобы наоборот Это нужно для тех, кто числа такого мог не видеть раньше в таком значении, по разным причинам.
Дык, пусть учатся. Планка должна задаваться не по самому глупому или малоопытному человеку в команде, а наоборот, в идеале. Требование для программиста "суметь найти в интернете описание" я не считаю высоким. Специально сейчас попробовал найти в MSDN константу FDFDFDFD — сразу получил ссылку на соответствующую статью.
LMA>>Я уже писал выше, что любое правило можно довести до полного идиотизма:
A>А зачем?
Ответ на вопрос "Неужто нельзя придумать константе имя, чтобы бы оно было, по крайней мере, такое же информативное, как значение константы?"
Или конкретно имя empty_sum не нравится?
LMA>>
LMA>>const int empty_sum = 0;
LMA>>int sum = empty_sum;
LMA>>while (q()) sum += f();
LMA>>
LMA>>Нравится, наверное, код, да?
A>Против арифметического "0" ничего не имею, эту константу действительно все знают и именно под таким обозначением
Т.е. "За, но иногда против" нравится?
A>В отличии от... ну, ты знаешь какого числа
Кто чего не знает — угадать невозможно. Если программист не сейчас что-то придумал (например, такую константу), а помнит её (и не забудет через пол года) — то логично, что он считает, что и другие её помнят. Это не задача программиста — сидеть и угадывать, что знают все, а что знают единицы. Если программист будет соц.опросы устраивать на тему: "а вам понятно, что есть "int sum = 0;", то производительность труда его будет "не айс" . В конце концов, если действительно членам команды, которым действительно с этим кодом работать, скажут на code review, что не понятно это им — можно будет решать — толи исправлять, толи орг.выводы делать относительно тех, кому не понятно — это уже зависит от того, что именно им не понятно.
Re[25]: Оцените код
От:
Аноним
Дата:
11.09.08 16:03
Оценка:
Здравствуйте, LordMAD, Вы писали:
LMA>Кто чего не знает — угадать невозможно. Если программист не сейчас что-то придумал (например, такую константу), а помнит её (и не забудет через пол года) — то логично, что он считает, что и другие её помнят. Это не задача программиста — сидеть и угадывать, что знают все, а что знают единицы. Если программист будет соц.опросы устраивать на тему: "а вам понятно, что есть "int sum = 0;", то производительность труда его будет "не айс" . В конце концов, если действительно членам команды, которым действительно с этим кодом работать, скажут на code review, что не понятно это им — можно будет решать — толи исправлять, толи орг.выводы делать относительно тех, кому не понятно — это уже зависит от того, что именно им не понятно.
ага, когда программистов ровно 3 и сидят они в одной кучке. А когда их 103 и сидят они в разных странах, вот тогда появляются проблемы
Здравствуйте, Аноним, Вы писали:
LMA>>Кто чего не знает — угадать невозможно. Если программист не сейчас что-то придумал (например, такую константу), а помнит её (и не забудет через пол года) — то логично, что он считает, что и другие её помнят. Это не задача программиста — сидеть и угадывать, что знают все, а что знают единицы. Если программист будет соц.опросы устраивать на тему: "а вам понятно, что есть "int sum = 0;", то производительность труда его будет "не айс" . В конце концов, если действительно членам команды, которым действительно с этим кодом работать, скажут на code review, что не понятно это им — можно будет решать — толи исправлять, толи орг.выводы делать относительно тех, кому не понятно — это уже зависит от того, что именно им не понятно.
А>ага, когда программистов ровно 3 и сидят они в одной кучке. А когда их 103 и сидят они в разных странах, вот тогда появляются проблемы
Наоборот, чем команда больше, тем это работает лучше, потому что координатор code review в любом случае должен состав участвующих делать репрезентативным по отношению ко всей команде. А вот в маленьких командах есть вероятность, что вся команда код пропустит дальше, а при вливании в команду новых людей — для них такой код будет проблемой, поэтому в маленьких командах приходится привлекать людей из других команд. Кроме того, в насколько маленьких командах (3 человека), code review стараются сделать менее формальным, что негативно сказывается на координации code review.
Здравствуйте, LordMAD, Вы писали:
LMA>Дык, пусть учатся. Планка должна задаваться не по самому глупому или малоопытному человеку в команде, а наоборот, в идеале. Требование для программиста "суметь найти в интернете описание" я не считаю высоким. Специально сейчас попробовал найти в MSDN константу FDFDFDFD — сразу получил ссылку на соответствующую статью.
Везет тебе, ты знаешь, что искать надо в MSDN Другой бы, увидевший 0xFD первый раз, сначала поискал в исходниках, потом во внешних хедерах, потом стал бы дергать коллег... Вобщем, потратил бы на свое обучение времени несоразмерно с реальной полезностью этого знания.
LMA>>>Я уже писал выше, что любое правило можно довести до полного идиотизма:
A>>А зачем?
LMA>Ответ на вопрос "Неужто нельзя придумать константе имя, чтобы бы оно было, по крайней мере, такое же информативное, как значение константы?" LMA>Или конкретно имя empty_sum не нравится?
Нравится, только оно ничего не упрощает для понимания, а значит является лишним.
LMA>>>
LMA>>>const int empty_sum = 0;
LMA>>>int sum = empty_sum;
LMA>>>while (q()) sum += f();
LMA>>>
LMA>>>Нравится, наверное, код, да?
A>>Против арифметического "0" ничего не имею, эту константу действительно все знают и именно под таким обозначением
LMA>Т.е. "За, но иногда против" нравится?
Даже больше, в случае с любым числом, используемым в контексте как абстрактное число (например, в математических вычислениях), я определенно за такие исключения. И люди со здравым смыслом это и так понимают, я думаю.
A>>В отличии от... ну, ты знаешь какого числа
LMA>Кто чего не знает — угадать невозможно. Если программист не сейчас что-то придумал (например, такую константу), а помнит её (и не забудет через пол года) — то логично, что он считает, что и другие её помнят. Это не задача программиста — сидеть и угадывать, что знают все, а что знают единицы. Если программист будет соц.опросы устраивать на тему: "а вам понятно, что есть "int sum = 0;", то производительность труда его будет "не айс" . В конце концов, если действительно членам команды, которым действительно с этим кодом работать, скажут на code review, что не понятно это им — можно будет решать — толи исправлять, толи орг.выводы делать относительно тех, кому не понятно — это уже зависит от того, что именно им не понятно.
Дык, правило, что надо именовать все константы, и избавляет программиста от необходимости думать, кто что знает. Если число имеет смысл отличный от абстрактного ноль икс эф дэ, опиши этот смысл в имени и используй имя. Почему даже MS в crt использует имя, а ты считаешь, что тебе это не нада?
Здравствуйте, ancient, Вы писали:
LMA>>Дык, пусть учатся. Планка должна задаваться не по самому глупому или малоопытному человеку в команде, а наоборот, в идеале. Требование для программиста "суметь найти в интернете описание" я не считаю высоким. Специально сейчас попробовал найти в MSDN константу FDFDFDFD — сразу получил ссылку на соответствующую статью.
A>Везет тебе, ты знаешь, что искать надо в MSDN Другой бы, увидевший 0xFD первый раз, сначала поискал в исходниках, потом во внешних хедерах, потом стал бы дергать коллег... Вобщем, потратил бы на свое обучение времени несоразмерно с реальной полезностью этого знания.
Даже если так. Поиск в исходниках и хидерах — это кнопку нажать в любой уважающей себя среде. Целых две секунды вместе с поиском! По сравнению с альтернативой — обучением писавшего программиста телепатии — не очень много.
Если имеет место практика "дерганья коллег" — это к менеджменту, заранее распечатав, скажем, это (на всякий случай, пункт 9 выделяем маркером), раз сами не понимают. Это не один раз пригодится.
LMA>>Ответ на вопрос "Неужто нельзя придумать константе имя, чтобы бы оно было, по крайней мере, такое же информативное, как значение константы?" LMA>>Или конкретно имя empty_sum не нравится?
A>Нравится, только оно ничего не упрощает для понимания, а значит является лишним.
LMA>>>>
LMA>>>>const int empty_sum = 0;
LMA>>>>int sum = empty_sum;
LMA>>>>while (q()) sum += f();
LMA>>>>
LMA>>>>Нравится, наверное, код, да?
A>>>Против арифметического "0" ничего не имею, эту константу действительно все знают и именно под таким обозначением
Должна быть причина для того, чтобы для константы заводить имя (просто потому, что это увеличивет объем кода на строчку), а не наоборот.
Просто прочти, например, Code Complete Макконнелла или другую какую азбуку — там ты найдешь причины, по которым константам дают имена — ни одна из этих причин к обсуждаемым константам не относится.
LMA>>Т.е. "За, но иногда против" нравится?
A>Даже больше, в случае с любым числом, используемым в контексте как абстрактное число (например, в математических вычислениях), я определенно за такие исключения. И люди со здравым смыслом это и так понимают, я думаю.
И люди со здравым смыслом и минимальным опытом отладки, когда они пишут именно под MS VS, 0xFDFDFDFD и так понимают, я думаю.
LMA>>Кто чего не знает — угадать невозможно. Если программист не сейчас что-то придумал (например, такую константу), а помнит её (и не забудет через пол года) — то логично, что он считает, что и другие её помнят. Это не задача программиста — сидеть и угадывать, что знают все, а что знают единицы. Если программист будет соц.опросы устраивать на тему: "а вам понятно, что есть "int sum = 0;", то производительность труда его будет "не айс" . В конце концов, если действительно членам команды, которым действительно с этим кодом работать, скажут на code review, что не понятно это им — можно будет решать — толи исправлять, толи орг.выводы делать относительно тех, кому не понятно — это уже зависит от того, что именно им не понятно.
A>Дык, правило, что надо именовать все константы, и избавляет программиста от необходимости думать, кто что знает. Если число имеет смысл отличный от абстрактного ноль икс эф дэ, опиши этот смысл в имени и используй имя. Почему даже MS в crt использует имя, а ты считаешь, что тебе это не нада?
Здравствуйте, slavo, Вы писали:
S>тихо, тихо. только не все сразу, вакансии кончились
а вот мимо этого я не пройду! типа анекдот.
белоснежка гуляла по лугу и собирала ромашки. жара разморила ее, и она прилегла в теньке поспать. мимо проходила корова и задела выменем лицо белоснежки.
— мальчики, мальчики, не все сразу! — спросонок бормотала белоснежка.
в отличие от многих тут
