Не важно для чего формулируются требвания. Если они сформулированы, им нужно соответствовать. 


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

Если первая команда не декларирует, что значение константы PI представляет число PI, то любое использование этой константы второй командой является ошибкой - использованием недокументированной фичи. В свою очередь, и эта ошибка может не приводить к проявлению багов. До поры, до времени.

Это сообщение отредактировал(а) Zloxa - 8.10.2013, 10:41

Можно даже ввести понятие круглого метра с определением: круглый метр есть единица площади круга, равная площади круга, радиус которого равен метру, заложить коэффициент 3.1415926535897932384626433832795 в функцию возведения в степень при показателе, равном 2, а саму вторую степень назвать не квадратом, а кругом и положить s=PI*a^2 формулой площади квадрата ("эс равно пи а круг") и ещё предусмотреть перевод площади перед выводом на экран из круглых метров в общепринятые квадратные, тогда PI будет равно 0.31830988618379067153776752674503. Если от программы будут требоваться площади, а не степени, то это не ошибка.

Добавлено через 2 минуты и 59 секунд
Которая читает, чему она равна, не в справочнике по математике, а в писанине первой группы. Я не призываю усложнять этим способом исходные тексты, но если уж так сделали, то и это правильно, просто не оптимально, но не ошибочно.

Добавлено через 6 минут и 8 секунд
А откуда они в таком случае вообще знают о её существовании? Мне как то попадалась константа PI=1.5707963267948966192313216916398, и ничего. Я безглючно использовал её в тригонометрии с градусами вместо радианов.

Не важно откуда они узнали о ее существовании. Если не из документации/спецификации, это недокументированная особенность, которую можно использовать лишь на свой страх и риск. И если вдруг с выходом патча, окажется что значение этой константы изменилось, поставщику фреймворка/библиотеки/инструмента, предъявить будет нечего, на его баг трекере топик будет закрываться как not a bug.

не, число её интерпретаций не счетно.


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

Константа уже скомпилирована в старой версии и ни какие изменения не ведут к возникновению егога, так как приложение использует старое значение. Если же взялись перекомпилировать и при этом заменили версию некоторых сторонних файлов, так проверьте сначала, чему у вас константы стали равны и как стали вести себя функции, а то окажется, что функция round, которая раньше возводила число в круглую степень, теперь просто округляет до целых. Даже если функции берутся из динамической библиотеки, проверяйте версию сразу после загрузки приложения и если попали на незнакомую версию, сразу закрывайте с сообщением об отсутствии совместимости. Или таскайте за собой ту версию библиотеки, с которой прилада работает. А то потом окажется, что PI переопределена с учётом того, что пространство положено финслеровым, окружность стала квадратом, а окружностью что то совсем третье, а вы берёте не саму PI из файла деклараций, а библиотечную функцию, в код которой PI заложена и в разных версиях различно, а надо продолжать поддерживать евклидову геометрию, но теперь выкручивать её из финслеровой.

ТарасАтавин, столько условностей, рекомендаций и ухищрений вместо простой рекомендации следования одной простой истине - не плоди гoвнокод, следуй спецификации, опирайся на документацию  

Это сообщение отредактировал(а) Zloxa - 8.10.2013, 11:10

Я сейчас не лабу веду, а гoвнoкод при всей сложности своего сопровождения может не быть ошибочным. Избегать его надо не потому, что он означает ошибку, а потому, что повышает её вероятность. И сколь бы изящным код ни был, при использовании новых версий сторонних файлов всё равно надо проверять, не захотелось ли коллегам по гoвнoкодить, иначе именно изящный код и будет с ошибками. А если сторонние файлы линкуются динамически, то версию надо проверять в каждом сеансе.

Это сообщение отредактировал(а) ТарасАтавин - 8.10.2013, 11:17

ТарасАтавин, проверять, конечно надо. Но давайте исходить из того, что непредсказуемый результат может произойти в результате несчетного количества причин. Для проверки несчетного количества причин требуется несчетное количество ресурса. Подстелить соломки в местах наиболее вероятного падения, никогда не будет плохо, но всю поверхность земли соломой всяко не застелишь. Потому доверять таки - надо. И если в спецификации указано, что константа PI являет собой значение PI, то проверять ее соответствие спецификации нелепо. Если в спецификации не упомянута константа PI, то использование ее в продакшн системе нелепо. Если в спецификации указано, что функция не возвращает ноль, то проверять ее результат на равенство нулю перед делением - нелепо. Если же мы натолкнулись на не соответствующее спецификации поведение сторонней системы, лепить воркэраунд, который не будет работать при специфицированном поведении системы(как приведенный вами пример компенсации кривизны значения PI) - нелепо.

Это сообщение отредактировал(а) Zloxa - 8.10.2013, 11:58

1. Чётная ошибка, то есть две взаимокомпенсирующие ошибки ошибкой не являются.
2. По возможности следует избегать даже таких пар, сокращая чётную ошибку, подобно тому, как школьники сокращают множители числителя и знаменателя дроби, так как хоть ошибкой она и не является, но повышает вероятность возникновения обычной нечётной ошибки при взаимодействии третьего места в программе с одной из половин чётной ошибки.
3. Если используешь сторонние файлы, всегда проверяй значения всех используемых констант и поведение всех используемых функций.
4. При использовании любых функций из сторонних динамических библитоек или таскай за собой гарантировано совместимые версии всех библиотечных файлов (если можно), или проверяй установленную версию. Если разрешено первое, то можно сочетать.
5. Если программный продукт в целом содержит даже одну не чётную ошибку, то виноват в ней не тот, кто написал гoвнoкод, а тот, кто писал часть программы, отдаваемую конечному пользователю.
6. Даже если приложение глючит из-за ошибки в библиотеке/SDK/компиляторе, то ошибка заключается в неучёте ошибки в библиотеке/SDK/компиляторе.
7. Тем не менее гoвнoкодь только для компенсации ошибок в сторонних гoвнoфайлах.

Добавлено через 3 минуты и 44 секунды
Не счётное количество причин ни как не может проявляться в конкретно-ограниченном проекте, использующем лишь некоторые сторонние константы функции, а не множество всех возможных констант и функций. А непосредственно используемые вещи проверить можно. Если ты прыгаешь на батуте, то зачем тебе стелить соломку у подножия восьмитысячника на соседнем континенте? Проверь батут, ты не народ потомственных альпинистов.

Добавлено через 10 минут и 17 секунд
Согласен, внутренние соглашения и документация на весь полуфабрикат - разные вещи и если сказано, что PI - это математическая пи, то этому можно и довериться. А я вот читал, что PI - это пи попалам. И что им предъявить на такую константу? Речь не о том, что надо проверять ещё и соответствие чужих спецификаций действительности. Речь о том, что не стоит доверять одним лишь именам, а подглядывание в спецификацию - один из способов той самой проверки, иногда даже единственно доступный.

Разработчик компилятора/библиотеки/IDE/SDK может быть виноват в ошибке только в том случае, если он не описал её, как фичу, допустив её именно у себя. К константам даже это не относится, по ним вина в ошибке только в случае прямой лжи в спецификации, а если константу вообще забыли описать в спецификации, то её документирует декларация. Кому не нравятся кривые константы - переопределяйте самостоятельно. А если вдруг автор языка написал, что на его языке сложение имеет приоритет над умножением, то потрудитесь исправить в исходнике прилады с помощью скобок, или путём вычисления произведений в виде именованных промежуточных результатов.

архисерьёзная ошибка так думать

 Да, но он ведь может компенсировать её другой архисерьёзной ошибкой 

Во-первых, странный наезд по поводу английского языка. Bug можно перевести как глюк, это наиболее подходящее слово, потому что уже есть перевод error - ошибка. И потом, если вспомнить историю, то появление термина "bug" возникло после того, как в шкафообразной ЭВМ нашли жучка, из-за которого она неправильно работала, кажется это был мотыль, хотя это слабо относится к теме, так же как слово глюк - сокращение от слова "галлюцинация". Про инквизицию и мистику: а я разве говорил что в программах есть нечто мистическое? Про неожиданный эффект я не зря написал. Вы в курсе, что когда выпускаешь программный продукт, и пользователи начинают им пользоваться, то практически сразу обнаруживается куча ошибок? И это не зависит от степени "крутости" и "пряморукости" разработчиков - всего предусмотреть нельзя. Тут Билли бы меня поддержал, а упомянутые не к месту Папа Римский и иезуиты ничего бы не поняли - зачем это им? И почему, кстати, бывший глава MS должен что-то там оценивать? Он для Вас последняя инстанция в вопросах разработки и программирования? Возьмите того же Sonic'a, которого я привел в пример, да многие современные и старые игры тоже, а уязвимости в программных продуктах, это не неожиданные эффекты? Только про кривые алгоритмы согласен.

bug (клоп, жучок) уже в 19 веке означал дефект механизма, возможно с подачи Эдисона

###. холивар

скопипастил с википедии   



Добавлено через 4 минуты и 17 секунд
А вы различаете багу, борбагу, гейзенбагу, мандельбагу и шрёдинбагу?!?!?!?