Раз уж вопрос именно о способах увеличения надежности при проектировании ПО, то не грех вспомнить про формальное доказательство корректности программы.
Ещё желательно сразу предусматривать альтернативные каналы для внешних измерений
Всегда казалось, что исключения и всякого рода коды возвратов - это вещи взаимодополняющие.
Исключения нужны, чтобы подсветить косяк разработки. Мол, да, тут не доглядел, тут не проверил - придётся переделывать.
Коды возврата нужны, когда ожидание подвоха является частью логики программы. Например от какого-то не очень доверенного внешнего сервиса или от пользователя. Если учёл недостаточно, - исключения услужливо на это обратят твоё внимание
И всё же с бесконечными (±inf) не всё так однозначно. В качестве слагаемого он даст неопределённость (NaN) только с inf противоположного знака, либо с NaN.
Если же inf окажется в знаменателе, то запросто приведёт результат к обычному ±0.
В статье, как мне кажется, очень неплохо раскрыто, что практически даром можно заложить корректное поведение кода в пограничных случаях
Это не так работает (в отсутствие в коде намеренного рандома).
"Одинаковые вводные" = одинаковые исходные "стейты", базы данных, окружение (и его "стейты") и ввод.
Если в этом случае нечто даёт разные результаты, то, увы, это никак программой назвать нельзя. Соответственно, то на чём это написано, языком программирования тоже назвать не получится
Было бы умнстно дать хоть немного вводных.
Perplexity - это что?
Раз уж вопрос именно о способах увеличения надежности при проектировании ПО, то не грех вспомнить про формальное доказательство корректности программы.
Ещё желательно сразу предусматривать альтернативные каналы для внешних измерений
Ни к селу ни к городу.
BIM - это Building Information Modeling
Позор был бы, если бы упёрлись рогом и решили вкладываться в ТУ-144 до победного, вместо того, чтобы развивать региональную авиацию.
Бывает так, что пришедший первым просто раньше остальных осознаёт, что путь вёл в тупик
Всегда казалось, что исключения и всякого рода коды возвратов - это вещи взаимодополняющие.
Исключения нужны, чтобы подсветить косяк разработки. Мол, да, тут не доглядел, тут не проверил - придётся переделывать.
Коды возврата нужны, когда ожидание подвоха является частью логики программы. Например от какого-то не очень доверенного внешнего сервиса или от пользователя. Если учёл недостаточно, - исключения услужливо на это обратят твоё внимание
И всё же с бесконечными (±inf) не всё так однозначно. В качестве слагаемого он даст неопределённость (NaN) только с inf противоположного знака, либо с NaN.
Если же inf окажется в знаменателе, то запросто приведёт результат к обычному ±0.
В статье, как мне кажется, очень неплохо раскрыто, что практически даром можно заложить корректное поведение кода в пограничных случаях
Это не так работает (в отсутствие в коде намеренного рандома).
"Одинаковые вводные" = одинаковые исходные "стейты", базы данных, окружение (и его "стейты") и ввод.
Если в этом случае нечто даёт разные результаты, то, увы, это никак программой назвать нельзя. Соответственно, то на чём это написано, языком программирования тоже назвать не получится