Мы все отлично понимаем, что запретить что-либо врядли у кого-либо получится. Однако мы также понимаем, что если кто-то очень сильно захочет создать серьезные проблемы, то он их создаст!
Вспомним истерию вокруг SOPA. Как мы тогда всполошились. А все почему? Потому что в штатах расположено очень много вычислительных ресурсов, так значимых для всего мира, а не отдельного государства! Так и тут, если ФБР пример этот закон, то будет иметь возможности закрывать неугодные им вычислительные ресурсы. К примеру неугодный сервер с опен-сорц проектом. А если учесть, что в мире опен-сорца очень дико радуются очередному зеркалу или другому ресурсу, то этот закон реально может доставить неудобства.
На мой взгляд, если кто-либо когда-либо осилит заставить опен-сорц проекты вставлять «не юзер френдли код», то это означает большие проблемы для очень большого количества пользователей!
Все потому что громадное количество пользователей опен-сорца не являются программерами! Они просто умеют юзать команды а-ля «make install clean», а это уже проблемы. Можно конечно освещать в анонсах к примеру такими строками: «мы по требованию властей вынуждены были вставить код делающий....», но абсолютно весь код который коммитится такими анонсами не покрыть!
Ну и в добавок хочу отметить, что также в коде использую еще одну практику:
Если текст условия больше чем 25 символов, то нужно либо посмотреть в название переменных, либо составить несколько bool переменных.
Ранее у программеров была эмпирическая оценка — не больше 86 символов на строку.
1) sizeof(«boost::filesystem::file_size(fpath) < minPackedImageSize && dosHeader.e_lfanew<= boost::filesystem::file_size») больше 25 символов
2) sizeof(«boost::filesystem::file_size(fpath) < minPackedImageSize») больше чем 25!!!
3) sizeof(«dosHeader.e_lfanew <= boost::filesystem::file_size») больше чем 25
Этот доп. признак позволяет мне обратить внимание на плохо написанное условие с точки зрения эстетики, а следовательно и читабельности кода.
т.е. благодаря этому признаку, я смог остановить на «паузу» свой мозг и посмотреть на этот «дурно пахнущий» кусок кода. В спешке я бы не заметил этого.
Всегда без скобок из-за того что затрудняют понимание. Если же условие обретает форму, когда больше чем 2 под-условия, то разбиваю условие на несколько bool-евых флагов, которые читать проще.
А Вы сидите и помалкивайте об этом, а то не ровен час кто-нить запатентует и будете помимо налога на воду\газ\электричество еще и за это отчислять. Но вообще стремно как-то, если рисуемая картинка мозгом, где я отправляю яндекс-деньги за общение на русском будет осуществлена… Чур… Чур Чур Меня!
Поясню мысль, возможно Вы не поняли то что я хотел донести. Если ошибаюсь поправьте или укажите на багу в моих рассуждениях.
assert — с англ. на русс. «утверждаю», своего рода конструкция, которая позволяет программисту документировать код. Написав assert он словно говорит «Утверждаю, что в этом месте не должно быть ....» и говорит он это своему коллеге по ремеслу, который будет поддерживать исходный код в будущем. Пишем мы assert-ы не просто так, а потому что наиболее дешевый способ узнать об ошибках в голове программиста, который писал код.
Особенность assert-ов в том, что их принято выпиливать из релизных билдов. И именно поэтому дебажная версия ядра так заметно медленней работает чем релизная, потому что там есть assert-ы.
BugCheck() — это аналог assert-а, но не выпиливаемый из релизного билда. Ставится он настолько редко, что встретив его в коде понимаешь, что в этом куске кода нужно быть предельно внимательным и аккуратным. Он также как и assert служит своего рода «средством документирования». Это как раз тот самый инструмент, когда программер очень сильно сомневается в коде, а ничего в данный момент существенного по каким-либо причинам сделать не может, но при этом на «авось» оставить не желает. Что делать? Ответ надо написать «Я чего-то тута намудрил, если тут чего-то возникнет посмотри на реальной боевой ситуации как можно выкрутиться» и чтобы такое написать как раз и следует использовать BugCheck()
Согласен, что каждому свое.
Только вот человек вроде как спрашивал о том как избежать BSoD
>>это именно ошибки проектирования драйвера
Согласен, тут не спорю. :) Но этот BugCheck как раз тот самый assert, который категорически нельзя выпиливать из релизного билда.
На мой взгляд Вы всего-лишь догадываетесь, что такое «программирование под Ring-0».
>>что ничего страшного с ядром не случилось, и пользователь, как минимум, сможет сохранить свои файлы и перезагрузиться самостоятельно?
Именно для этого и придумали BSOD и его не следует избегать! Если разработчик драйвера решил, что именно тут нужно «упасть», значит это действительно правильное решение и оно должно быть тут!!!
Все дело в том, что «драйверисты» это весьма серьезные ребята. Процент толковых ребят среди «драйверистов» значительно превосходит другие проценты скажем в C++, PHP, Python, etc. В область разработки драйверов просто так не попадают. Чтобы запустить простейший «hello world» нужно самому себе не кисло мозг выкрутить. А если еще учесть, что до промышленной разработки допускаются, как правило, еще и люди с опытом в 3-5 лет, то мне если честно совсем не приходит в голову мысль «а давайте-ка похучим и избежим BSoD».
Приведу одну из ситуаций, где нужно использовать assert. К примеру Вы только вчера вышли на новую работу и Вам дали проект с большим количеством строк. В проекте Вы еще ничего не знаете и только еще приступили разбираться. Перед Вами поставлена задача за 1-2 дня поправить багу и выкатить новый update. В ходе работы с кодом и его отладкой вы вдруг находите багу. Допустим она в неком хитро-вывернутом цикле с некисло написанным коде, который не мешало бы отрефакторить. Цикл помещен в функцию которая очень часто вызывается и тем самым влияет на эффективность работы приложения, к примеру подбор пароля.
Каковы Ваши действия?
На мой взгляд такие варианты:
1) Просто внести изменения в код, тем самым поправить багу. Выкатить обновление. Отрапортовать о выполнении задачи шефу.
2) Вы непросто фиксаете код, но и попутно пишите unit-тест, который в будущем позволит Вам или Вашим коллегам проверить этот цикл на корректность работы.
3) Вы фиксаете код и пишите assert.
Выводы:
1) Если идти по варианту №1 то в будущем вы можете забыть работу этого цикла и снова придется вникать
2) Если же идти по варианту №2, то Вы можете не уложиться в отведенные на задачу 1-2 дня!!!
3) Самое наилучшее решение, этим самым вы говорите самому себе в будущем и своим коллегам «Утверждаю что в этом коде переменная1 не должна быть больше чем переменная2», ну или еще чтото.
Если вы пойдете по варианту №3, то выкатив на рынок обновление ПО Вы никак не ухудшите его работу по скорости, т.к. лишней проверки assert нету в релизе.
Однако при этом в случае проблем Вы имеет возможность скомпиллировать дебажную версию и получить так нужные вам assert-ы, которые помогают вам понять докопаться до проблемы
В одном комментарии Вы пишете:
>>31 марта 2012, 16:25
>>Ассерты из кода релизных билдов выключать ВРЕДНО
А в другом:
>>31 марта 2012, 16:42
>>Считаете, кастомеру больше понравится неопределённое поведение? Особенно он будет счастлив, когда Вы не сможете его локализовать и исправить.
То что кастомеру больше понравиться… ежу понятно и это даже не обсуждается именно за тем и работает программер, что меньше парить мозг кастомеру. С этим ни кто не спорит!
Ваше слова про ассерт, что их нужно оставлять в релизе говорят о том что Вы не совсем понимаете смысл и цель существования assert!!! Вы путаете понятие assert c проверкjq, которая проверяет что-то в коде и в случае чего правильно валит программу либо еще что-то!
Обратите внимание на перевод слова «assert» с англ. на русский. «утверждаю». Это своего рода документация на исходный код потомкам «Утверждаю что в этом месте не должно быть....». Это совсем другое и отличное от привычных нам конструкций в коде на вроде: «Если вдруг значение переменной икс больше… тогда покажем багрепорт».
По ссылке указанной вами комент за «31 марта 2012, 16:42», а я же ответил на «31 марта 2012, 16:25». Не заметили? Вот последний как раз содержит весьма плохо-пахнущую практику «Ассерты из кода релизных билдов выключать ВРЕДНО». Перечитайте внимательней мой коммент.
Написал бы уж конкретный пример применяемый в боевой ситуации, к примеру вычисление дельта смещения под 32-бита:
Вспомним истерию вокруг SOPA. Как мы тогда всполошились. А все почему? Потому что в штатах расположено очень много вычислительных ресурсов, так значимых для всего мира, а не отдельного государства! Так и тут, если ФБР пример этот закон, то будет иметь возможности закрывать неугодные им вычислительные ресурсы. К примеру неугодный сервер с опен-сорц проектом. А если учесть, что в мире опен-сорца очень дико радуются очередному зеркалу или другому ресурсу, то этот закон реально может доставить неудобства.
Все потому что громадное количество пользователей опен-сорца не являются программерами! Они просто умеют юзать команды а-ля «make install clean», а это уже проблемы. Можно конечно освещать в анонсах к примеру такими строками: «мы по требованию властей вынуждены были вставить код делающий....», но абсолютно весь код который коммитится такими анонсами не покрыть!
А чем латиница не устраивает?
Если текст условия больше чем 25 символов, то нужно либо посмотреть в название переменных, либо составить несколько bool переменных.
Ранее у программеров была эмпирическая оценка — не больше 86 символов на строку.
Пример:
1) sizeof(«boost::filesystem::file_size(fpath) < minPackedImageSize && dosHeader.e_lfanew<= boost::filesystem::file_size») больше 25 символов
2) sizeof(«boost::filesystem::file_size(fpath) < minPackedImageSize») больше чем 25!!!
3) sizeof(«dosHeader.e_lfanew <= boost::filesystem::file_size») больше чем 25
Этот доп. признак позволяет мне обратить внимание на плохо написанное условие с точки зрения эстетики, а следовательно и читабельности кода.
Разбиваю на:
т.е. благодаря этому признаку, я смог остановить на «паузу» свой мозг и посмотреть на этот «дурно пахнущий» кусок кода. В спешке я бы не заметил этого.
пример разбития на несколько под условий:
assert — с англ. на русс. «утверждаю», своего рода конструкция, которая позволяет программисту документировать код. Написав assert он словно говорит «Утверждаю, что в этом месте не должно быть ....» и говорит он это своему коллеге по ремеслу, который будет поддерживать исходный код в будущем. Пишем мы assert-ы не просто так, а потому что наиболее дешевый способ узнать об ошибках в голове программиста, который писал код.
Особенность assert-ов в том, что их принято выпиливать из релизных билдов. И именно поэтому дебажная версия ядра так заметно медленней работает чем релизная, потому что там есть assert-ы.
BugCheck() — это аналог assert-а, но не выпиливаемый из релизного билда. Ставится он настолько редко, что встретив его в коде понимаешь, что в этом куске кода нужно быть предельно внимательным и аккуратным. Он также как и assert служит своего рода «средством документирования». Это как раз тот самый инструмент, когда программер очень сильно сомневается в коде, а ничего в данный момент существенного по каким-либо причинам сделать не может, но при этом на «авось» оставить не желает. Что делать? Ответ надо написать «Я чего-то тута намудрил, если тут чего-то возникнет посмотри на реальной боевой ситуации как можно выкрутиться» и чтобы такое написать как раз и следует использовать BugCheck()
Только вот человек вроде как спрашивал о том как избежать BSoD
>>это именно ошибки проектирования драйвера
Согласен, тут не спорю. :) Но этот BugCheck как раз тот самый assert, который категорически нельзя выпиливать из релизного билда.
>>что ничего страшного с ядром не случилось, и пользователь, как минимум, сможет сохранить свои файлы и перезагрузиться самостоятельно?
Именно для этого и придумали BSOD и его не следует избегать! Если разработчик драйвера решил, что именно тут нужно «упасть», значит это действительно правильное решение и оно должно быть тут!!!
Все дело в том, что «драйверисты» это весьма серьезные ребята. Процент толковых ребят среди «драйверистов» значительно превосходит другие проценты скажем в C++, PHP, Python, etc. В область разработки драйверов просто так не попадают. Чтобы запустить простейший «hello world» нужно самому себе не кисло мозг выкрутить. А если еще учесть, что до промышленной разработки допускаются, как правило, еще и люди с опытом в 3-5 лет, то мне если честно совсем не приходит в голову мысль «а давайте-ка похучим и избежим BSoD».
Каковы Ваши действия?
На мой взгляд такие варианты:
1) Просто внести изменения в код, тем самым поправить багу. Выкатить обновление. Отрапортовать о выполнении задачи шефу.
2) Вы непросто фиксаете код, но и попутно пишите unit-тест, который в будущем позволит Вам или Вашим коллегам проверить этот цикл на корректность работы.
3) Вы фиксаете код и пишите assert.
Выводы:
1) Если идти по варианту №1 то в будущем вы можете забыть работу этого цикла и снова придется вникать
2) Если же идти по варианту №2, то Вы можете не уложиться в отведенные на задачу 1-2 дня!!!
3) Самое наилучшее решение, этим самым вы говорите самому себе в будущем и своим коллегам «Утверждаю что в этом коде переменная1 не должна быть больше чем переменная2», ну или еще чтото.
Если вы пойдете по варианту №3, то выкатив на рынок обновление ПО Вы никак не ухудшите его работу по скорости, т.к. лишней проверки assert нету в релизе.
Однако при этом в случае проблем Вы имеет возможность скомпиллировать дебажную версию и получить так нужные вам assert-ы, которые помогают вам понять докопаться до проблемы
В одном комментарии Вы пишете:
>>31 марта 2012, 16:25
>>Ассерты из кода релизных билдов выключать ВРЕДНО
А в другом:
>>31 марта 2012, 16:42
>>Считаете, кастомеру больше понравится неопределённое поведение? Особенно он будет счастлив, когда Вы не сможете его локализовать и исправить.
То что кастомеру больше понравиться… ежу понятно и это даже не обсуждается именно за тем и работает программер, что меньше парить мозг кастомеру. С этим ни кто не спорит!
Ваше слова про ассерт, что их нужно оставлять в релизе говорят о том что Вы не совсем понимаете смысл и цель существования assert!!! Вы путаете понятие assert c проверкjq, которая проверяет что-то в коде и в случае чего правильно валит программу либо еще что-то!
Обратите внимание на перевод слова «assert» с англ. на русский. «утверждаю». Это своего рода документация на исходный код потомкам «Утверждаю что в этом месте не должно быть....». Это совсем другое и отличное от привычных нам конструкций в коде на вроде: «Если вдруг значение переменной икс больше… тогда покажем багрепорт».