Pull to refresh

Comments 118

Вот интересно, они(NASA) планируют использовать Rust? Вроде, язык хорошо подходит под их цели, множества ошибок помогает избежать.
Думаю они не изменят свои методы
UFO just landed and posted this here
А вам советую подумать о том, что когда мы говорим о проектах, которые занимают десятилетия (от момента запуска до точки назначения зачастую полёты годы занимают), то язык, первый релиз которого вышел чуть больше года назад — это просто несерьёзно. Вот пройдёт лет 10 — можно будет о чём-то говорить.
А на каком языке они по вашему писали в 70е?
Там несколько языков было. Ассемблер, виртуальная машина от MIT и прочее, но, уж конечно, не С. С там появился, скорее всего, в 80е, примерно когда Space Shuttle начали разрабатывать.
Кого начали? Когда начали?

Space Shuttle полетел в 1981 году.
То есть шли на риск использовать технологию моложе 10 лет?
Что-то железячное могли писать на Ada — с полгода назад на гиктаймсе статья пролетала, что в НАСА скоро останутся без последнего разработчика, способного что-либо сделать с Вояджером (кажется) — ибо док уже нет, спец остался один и тот имеет очень пенсионный возраст…
На Ada и сейчас пишут, пишут активно. И железное, и высокоуровневое. В NASA, ESA. Как у нас — не знаю, слишком мало информации у меня.
UFO just landed and posted this here
Сразу видно что вы ничего не знаете про rust. Он будет работать и на контроллере и на эльбрусе. А уж с интеграцией в си проекты вообще никаких проблем.
К тому же никто и не собирается переписывать все что есть, речь про написание нового кода.
UFO just landed and posted this here
Не нужно переписывать/отказываться от старого кода, он без проблем подключается и применяется.

Ответ на вопрос «зачем?» заключается в наличии гарантий безопасного управления памятью без оверхеда на это в рантайме. Именно это бич Си, именно это могло бы пригодиться в NASA для сверхнадёжных программ.
Только не надо говорить, что это не проблема, это уже стоило человечеству очень многие миллионы долларов в ретроспективе.

Но, естественно, нет смысла в NASA переключать сейчас разработку на RUST 1.0.сколько-то.alpha, надо дождаться стабильной стандартизированной проверенной версии, полностью на 100% отлаженного и доверенного компилятора и т.д.
Рассматривать в перспективе есть смысл, чисто из-за этой фишки с памятью.
UFO just landed and posted this here
есть одна мааааленькая проблема:
для RUST наверняка нужен процессор с MMU (memory managment unit — блок переназначения виртуальной памяти в физическую).
А это и падение быстродействия, и требование наличия ОС, и в разы больше транзисторов и триггеров.
А всё это даёт дополнительные точки отказа, особенно в среде с повышенной радиацией, а по «праздникам» с зашкаливающей радиацией. Что есть не самая лучшая идея особенно ради просто моды.

Ладно, чёрт с ней с физикой и сложностью.
Мне вот интересно другое: есть ли методика безопасного кодинга, проверки и поиска ошибок для RUST выстраданная десятилетиями и миллиардами долларов убытков? Надёжные инструменты которые не дают незначительные ошибки раз в 100000 строк кода? Проверенные годами библиотеки? Надеюсь за фанатов что есть.
для RUST наверняка нужен процессор с MMU (memory managment unit — блок переназначения виртуальной памяти в физическую).
Нет, Rust'у нафиг не нужен MMU. И вообще он один из редких совеременных языков, способных на голом «железе» сидеть, без операционки, на микроконтроллере с ограниченной памятью.

Мне вот интересно другое: есть ли методика безопасного кодинга, проверки и поиска ошибок для RUST выстраданная десятилетиями и миллиардами долларов убытков?
Какие могут быть «выстраданные десятитителиями методики», если языку чуть больше года? Позаимствованные из других языков — да, есть, там много идей, «проверенных годами» идей, которые теоретически должны обеспечивать «безопасный кодинг», но как оно там на практике больших проектов в миллионы строк работать будет — ещё рано говорить.

Молодой Rust пока — это да, но задатки хорошие. Переводить на него всякие сильно критичные системы — я бы пока не стал. А вот какой-нибудь мелкий проект — уже вполне можно изображать…
Первая стабильная версия Rust вышла лишь в том году а вы хотите чтобы на нем писалось ПО для космических кораблей? Ну ну. Может лет так через 10, если язык покажет свою живучесть и станет более или менее стабильным, будет смысл поговорить об этом.
Си не универсальный

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

40 лет назад — это 76-й год. В то время в C был принят такой способ определения параметров у функции:


int foo(a, p) 
    int a; 
    char *p; 
{ 
    return 0; 
}

Более-менее современный C — это ANSI C 89-го года или ISO C99.

И кто мешает взять такой код и скомпилировать его сейчас? На любой платформе любой популярный компилятор его соберёт.
надо же собрался — никогда не задумывался об этом. жаль c++ не берет, а было бы удобно с трехэтажными шаблонизированными параметрами, что-то типа auto возвращаемого значения в c++11
Нарушите правило 10 :)

Любой современный компилятор на такую архаичную запись выдаст предупреждение.
UFO just landed and posted this here
И даже в C11. Потому что даже в C11 — это неотъемлемая часть языка C. Только в приложении «Future language directions» упоминается, что эта фича, в общем, довольно давно устарела и, возможно, когда-нибудь, от неё таки и откажутся. Может быть.

Я согласен с тем, что Rust хорошо сочетается с заявленными целями писать максимально безопасный код. Но если запретить динамическое выделение памяти, то его преимущества перед C радикально уменьшаются.


Don't get me wrong. Я люблю Rust и надеюсь, что он получит большее распространение в обозримом будущем.

Но все же, нет особой необходимости менять на Rust.
Для NASA может быть и нет. У них, надо полагать, все эти правила не только на бумажке написаны, но и проверяются статическими анализаторами и сотнями тестировщиков. А остальным, всё-таки, стоит задуматься.
Как вы собрались правило #2 будете проверять с указателями на функции?
Ну у выбранной функции (стратегии), которая вызывается по указателю, может быть такая проверка.
Это значит что нужно выходит за рамки C и расширять язык. Скорее всего они этим заниматься не хотят.
к чему эти уложения? чтобы сложнее проверять и легче допустить ошибку? а если марсоход встанет из-за этой ошибке. В их деле не стоит гнаться за скоростью написания кода
ЛЕГКО. Вызов функции по указателю просто не влияет на циклы.

Как пример использования. Есть функция — запаковать в пакет прикладного уровня и отправить. И у неё аргумент — функция отправки транспортного уровня. Транспортных подсистем — 3-4 штуки. Соответственно делаются обертки к функции запаковки — запаковать и отправить таким-то транспортом (или транспортом, указанным в конфиге).

В итоге получается достаточно безопасная конструкция.

Преимущество — память на прикладной конверт выделяется той функцией, которая знает, сколько памяти надо.

Все это можно сделать через свитч, но оно менее расширяемо получится.
Не ясно чем их заменить с C. Когда, к примеру, требуется вызов функции по системному таймеру, обычно адрес фукнции записывается в отведенную для вызовов таймера ячейку и при наступлении события таймер дергает функцию, адрес которой там указан. Чем заменить этот механизм?
Вероятно они предполагают писать статичный код целиком, то есть с известными именами функций и ветвлениями. Для небольших проектов такое могу представить.
Судя по правилам — они используют какой-то инструмент, перебирающий все доступные варианты ветвления (доказательство корректности программ?).
Я думаю, это обычный статический анализатор, и судя по тексту — общедоступный, а не какой-то свой.
UFO just landed and posted this here
А зачем этот механизм менять? Я так понимаю что контантные указатели на функции, обусловленные железом, не запрещены. Кроме того я уверен, что у них есть много высокоуровневого кода, который не влияет на выживаемость железяки и для него требования не такие жёсткие…
Перевод неверный или исходник перевода сам корявый. По той же ссылке на оригинальные правила:

*29 Do not use non-constant function pointers.
30 Do not cast function pointers into other types.

UFO just landed and posted this here
Вычислимые адреса переходов/вызовов чреваты непредсказуемостью поведения программы так сказать второго рода, когда некорректные входные данные способны не только породить некорректные выходные (GIGO), но и разрушить логику работы конечного автомата — а это может привести к полному краху системы.

В случае же, когда все переходы определены в статике, бортовая вычислительная система представляет собой конечный автомат с памятью, который всегда можно перезапустить очисткой (приведением) набора входных данных к валидному состоянию.

Все вышесказанное, конечно, имеет смысл либо для гарвардских архитектур, либо для систем с защитой памяти (не обязательно имеющих виртуальную!)

Динамическая память — туда же. При отсутствии механизма виртуальной памяти невозможно гарантировать 100% корректную работу системы в течение бесконечного времени при динамическом выделении/освобождении памяти даже при любом априори предустановленном суммарном лимите для каждого процесса из-за фрагментации. При наличии механизма виртуальной памяти такое становится возможным — но взамен мы получаем лишь статистическую верхнюю границу времени отклика на выделение блока памяти
Невозможно (или слишком сложно) проверить корректность перехода по произвольному адресу, особенно когда данные и код в одном сегменте. При малейшей ошибке последствия очень плохие. Так что переход строго по константам со строгой типизацией. Если нужно разнообразие, то достаточно case.
Вот где реально интересно было бы посмотреть на результаты прогона PVS-Studio :)
Некоторые вещи в статике не протестируешь :)

У Европейского космического агенства была крутая новая ракета Cluster. Там дажу было горячее резервирование системы управления ракетой — но и оно не спасло от необработанного exception. Обе ноды синхронно упали :)

Эта неудача входит в список самых дорогих ошибок программистов
Вот где реально интересно было бы посмотреть на результаты прогона PVS-Studio :)


Кстати да. Призываю в тред Andrey2008
«The assertion density of the code should average to a minimum of two assertions per function.»

В среднем должно быть не менее двух ассершнов на функцию.
Дополню.
The return value of non-void functions must be checked by each calling function

Возвращаемое значение не-void фунций должно проверяться вызывающей функцией.

Примечание: идея такая, что функция не должна доверять ничему вообще, кроме себя самой, ни переданным аргументам, ни значениям полученным из других функций.

А я думаю — как assert(true) может помочь обойти правило не более двух ассертов.
Так намного больше смысла.

«10 правил, которые позволяют NASA писать миллионы строк кода с минимальными ошибками» —> «10 правил, которые заставляют NASA писать миллионы строк кода».
Крутая сатира. Поддел так поддел. В то время, когда любой программист на php/node может написать код для кьюриосити за два вечера и пару десятков тестовых запусков, nasa тратит десять лет на один-единственный запуск. Вот лузеры же.
Да… Как же плохо что программистов заставляют писать хороший код
Слышал что UI у spacex на HTML пишут. Может это все доказывает, что неважно какой язык, главное какие программисты?
А какая разница, на чем интерфейс отрисовывать?
Ну летите вы к земле, а на лендинг странице кнопочка приземления уехала.
насколько я понимаю, все важные кнопочки приземления выполнены в виде хардварных тумблеров. а интерфейс на хтмл — для разного рода научных программ и прочих тестов в невесомости.
скорее продублированы. Потому что экран может сломаться
Собственно, все самое интересное находится в документах MISRA C с примерами как делать хорошо и как плохо

Великолепные правила для неспешной разработки надёжных систем. Ужасные правила для быстрой разработки ненадёжных систем.


image

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


Хотелось бы узнать больше подробностей, ибо известно, что в общем случае проблема останова не решаема.
В общем случае рассматривается общая программа. Ваш КО.

Какой-нибудь BPF в проблему останова ни разу не упирается, почему NASA должна?
Какой-нибудь BPF в проблему останова ни разу не упирается, почему NASA должна?


Странная логика. Я не говорил, что "NASA должна".
В документе JPL есть много правил, но пользователь Реддита сделал выжимку десяти главных принципов.


то есть скорее всего есть какое-то формальное доказательство, что следуя всех их правилам, можно гарантировать, что программа завершиться за конечное число шагов. Я лишь хотел подчеркнуть, что вне контекста правило №2 непонятно совсем. Более того, непонятно, как его выполнять.
Правило совершенно понятно вне контекста, и, на мой взгляд абсолютно ясно, как его выполнять: не надо писать циклов неопределённой продолжительности. Наверняка, в других документах вдобавок прямо сказано, что любая процедура в прошивке космического корабля обязана гарантированно возвращать управление, скажем, не более чем через 100 мс.

На практике это означает, что сложные алгоритмы должны быть ограничены не только достижением результата, но и заданным количеством итераций до неуспеха.
Так они не программируют общий случай алгоритмов. Задача, вычислительная сложность которой неизвестна, не должна программироваться в бортовой компьютер.
Математическая поправка: машину Тьюринга нельзя построить, так как она сама по себе бесконечная (это требуется для доказательства некоторых теорем). Для алгоритма, выполняемого на конечной системе, всегда можно решить проблему остановки, так как она является тривиальной для такой системы. В этом случае машина Тьюринга будет эквивалентна некоторому большому конечному автомату (что, кстати, косвенно обсуждается в предложенных правилах от JPL), для которых существуют хорошие алгоритмы проверки формальной корректности.

Вот пример

http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20030017985.pdf

Да и вот тут много чего интересного есть

http://lars-lab.jpl.nasa.gov/
UFO just landed and posted this here
Просто ребята умно перефразировали «никогда не пишите while(true)» :)

Что-то я сомневаюсь, что дело в 10 правилах.


Дело скорее:
В детальном прописывании спецификаций и их низменности на протяжении всего времени разработки
В статическом анализе кода
В обязательном code review
В огромных затратах на тестирование


В таких условиях неважно на каком языке ты пишешь и какого стиля придерживается.


Очевидно, что правила про отсутствие динамической памяти, рекурсии, ограниченность циклов и отсутствие указателей на функции появились чтобы упростить работу статическому анализатору

UFO just landed and posted this here
Не-не-не, это как правила дорожного движения. Если их не соблюдать, то никакие навигаторы и техосмотры не помогут.

Анализатору и компилятору пофиг, он машина. Запятые, скобки на месте? Годен! А вот живому человеку сложно читать и отлаживать код, в котором много условностей и контекстов. Забудешь вернуть память или выйти из рекурсии — и привет. Проще это болото обойти, потратишь лишний час разработки, но сэкономишь недели и месяцы отладки.

На моей практике наблюдалось явление: чем больше код проверяется, тем внимательнее пишут программисты. Это касается именно проверки исходников, а не тестирования.


Добавляя статические проверки и code review к процессу можно сразу получить на порядок лучшее качество.
Видимо срабатывает логика: код будут проверять — надо писать хорошо. И обратная логика тоже работает прекрасно. Если никто по факту не код не проверяет, то пишут его абы-как.

Тут дело не в качестве, а в сознательном отказе от использования вполне корректных и полезных, но потенциально опасных возможностей.

Еще раз повторю тезис.


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


А если заранее спланировать что напишет программист, проверить статическим анализатором, прогнать через code review минимум двух человек и потратить в два раза больше времени на тестирование, то по сути пофиг какие там ограничения вы себе навводили.

Говнокод писать можно и нужно. Потому что у кода, от которого зависит сохранность имущества и жизни людей нет оценки говно-охуенно. Он либо работает как надо в любой ситуации, либо не работает и происходят плохие вещи. А как оно там внутри, грамотно или говняно — никого совершенно не интересует.

Вот, к примеру, 5-й пункт про ассерты. Они никак не влияют на функционал, это тесты. Они жрут такты при каждом вызове функции, особенно в циклах. Но это самые точные тесты, которые легко поддерживать актуальными. А еще они, в отличии от юнит-тестов, способны сохранить программу «на плаву» уже в полете, когда невозможное случилось и без отладчика точно указать на проблемное место.

или 7-й пункт, проверять все, что пришло снаружи или изнутри, будь то параметры или результаты. Например, банальная функция инкремента. Знаете, что будет с байтом 0xFF, если его увеличить на единицу? Будет ноль. А это во некоторых случаях может привести к беде. Поэтому в самом инкременте должен быть ассерт на переполнение, и на выходе нужно проверить, что результат инкремента является допустимым. Глупости? Отнюдь! Реальный пример — при формировании более светлого цвета фона для выделения важного сообщения происходило переполнение байтов RGB и получался черный текст на черном фоне. 15 лет работало нормально, а потом в системе поменяли цвет фона на чисто белый (0xFFFFFF) и получился эпический фейл. Вот каким анализатором или code review можно было такое предусмотреть?

С указателями самая больная тема. Нетипизированные указатели это граната с обезьяной. Проще сразу отказаться, чем потом страдать. Память из кучи это по сути своп — там и фрагментация свободного места, и конфликты, и утечки. Когда используется всего 5-10% от свободного объема, то это незаметно. А когда памяти впритык, то начинает всякая фигня происходить. Может всплыть через месяц, через год. Поэтому тестирование таких вещей идет неделями с 10-кратной нагрузкой на пределе возможностей железа.
Низменность детально прописанных спецификаций — сильно!

Высокодуховный код безбажен по определению :)
Вспомнилась интересная (даже спустя 20 лет после написания) статья о том, как устроена работа в одной из групп, разрабатывающей ПО для бортовых систем шаттлов: They Write The Right Stuff. В числе прочего, в ней есть интересные данные по доле ошибок в расчете на количество строк кода, по объему и качеству спецификаций в проекте, а также по размеру его бюджета. Пара цитат, передающих общую идею:

«Our requirements are almost pseudo-code,» says William R. Pruett, who manages the software project for NASA. «They say, you must do exactly this, do it exactly this way, given this condition and this circumstance.»

The group has one customer, a smart one. And money is not the critical constraint.

Ничуть не принижая способности их разработчиков, следует отметить, что с организационной точки зрения условия им созданы очень близкие к идеальным.
У меня тоже задачи однозначны, просты и понятны, любой студент справится. Вся проблема в том, что в системе должно быть 0 (ноль) ошибок на 560 000 строк кода. И работать она должна несмотря ни на какие сбои и неполадки железа и софта, ошибки персонала. Но, в отличие от НАСА, денег и ресурсов минимум, а ответственность не меньше.

Скрытый текст
Пульт центрального наблюдения для ohrana.gov.by Немного почитать — www.serbod.com/projects-taken/rf-link

в системе должно быть 0 (ноль) ошибок на 560 000 строк кода. И работать она должна несмотря ни на какие сбои и неполадки железа и софта, ошибки персонала.

Стандартное в наши дни требование практически от любого заказчика в корпоративном сегменте :)

А если серьезно, то некоторые из описанных задач, конечно, далеко не для любого студента. Поделитесь, какими способами пытаетесь поддерживать низкое количество ошибок в системе, в которой есть сторонние компоненты, включая целые базы данных, а также
некоторые драйвера устаревших приборов невозможно протестировать и отладить, потому что они сложные, к ним нет ни документации, ни тестовых приборов

? Используете похожие на NASA'вские правила при разработке? Требуете как и они от заказчика подробнейшие спецификации? Содержите ли сильнейший отдел тестировщиков? Пытаетесь вытягивать на личных профессиональных качествах старших разработчиков?
Ошибки в коде для системы вовсе не повод, чтобы не работать. =) Система разбита на множество компонентов, и если ломается один, то остальные либо ждут его восстановления, либо переключаются на запасной. Главное, чтобы поставленные задачи решались в пределах допустимых отклонений от нормы. И не допускать повторения ошибок.

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


"В 1962 году головной по командному модулю кораблей серии «Аполлон» фирмой «North American Aviation» (позже — «North American Rockwell») при изменении технического задания на изготовление кислородных баллонов для двигательных отсеков, выданного субподрядчику фирме «Beech Aircraft», не была предусмотрена модификация термостатов, изначально рассчитанных на напряжение 28 В, под стандартное для наземного оборудования стартового комплекса напряжение в 65 В. Это несоответствие не было замечено ни специалистами обеих фирм, ни НАСА. [...] проведённые в ходе расследования эксперименты показали, что эти выключатели, рассчитаные на питание в 28 вольт постоянного тока от батарей служебного модуля, не размыкались должным образом при работе под напряжением 65 В, подаваемым со стартового комплекса в ходе выпаривания кислорода."
В NASA JPL большие молодцы. Но поучительно помнить, что все эти правила не помешали едва не угробить марсоходы… из-за банальной вещи — из-за того, что на Земле никто не протестировал случай, когда марсоход наделал много фотографий и его FLASH-память почти заполнилась.
Память закончилась не из за фотографий, а из за ошибки реализации файловой системы, которая приводила к неполному освобождению места при удалении файлов/папок.
Читал ровно эти самые десять правил лет 7 назад в каком-то англоязычном журнале, написано было один в один
Правило #7, кажется, называется defensive programming и считается немного противоречивым.
Для NASA — в самый раз. Подобный подход приводит к тому, что ошибки имееют меньше шансов привести к провалу миссии, но увеличивают вероятность того, что останется ошибка, которую сможет использовать «враг». Так как бортовому компьютеру с атаками на безопасность сталкиваться не приходится — то выбор очевиден.
UFO just landed and posted this here
Самая локальная. Ну это более или менее здравый смысл — если переменная нужна только в конкретном блоке кода, делать ее глобальной это заранее создавать себе крупные проблемы.
Эти правила просто напросто вытекают из ограничений той самой «проверяющей программы», которая вскользь упоминается в некоторых из них. Само собой, что если у тебя такая программа есть, то ты вынужден писать код таким образом, чтобы она могла его проверять. Но использовать эти правила, не имея в своём распоряжении проверяющей программы, — это то же самое, что и не иметь автомобиля, но при этом передвигаться в сидячей позе, выставив вперёд руки, которые, как бы, держат руль, и издавая ртом звуки, имитирующие работу двигателя.
Нет, к этим правилам рано или поздно приходит любой разработчик масштабной системы с высокими требованиями.

Когда я впервые столкнулся с этим при разработке под игровые приставки (на картриджах), то тоже был несколько скептичен. Зачем же себя так ограничивать? Но позже, при отладке совершенно непонятных рандомных глюков, постепенно пришлось отбрасывать весь синтаксический сахар, регламентировать работу с памятью и вставлять сотни ассертов. В итоге ошибка находилась, они могла быть совсем пустяковой, и не влиять на работу сразу, а вызывать сбой где-то в другом месте программы.

Я бы еще добавил, что очень важна строгая типизация и однозначно говорящие имена функций и переменных. Сколько угодно случаев, когда тупиковая ситуация переставала быть тупиковой, когда вещи называли своими именами.
Случаем, не так сделали?
#define TRUE 1
#define FALSE 0
typedef int BOOL;

// где-то в коде
BOOL a;
// повсеместно заместо
// a = TRUE;
a += 1;
У вас BOOL это синоним целого числа. В принципе, иногда допустимо, но тогда это iBool_t

enum Boolean { FALSE = 0, TRUE = 1 }; // ибо нефиг!
И объясняется это почти тем же самым. При разработке масштабных систем обычно происходит ревью кода другими разработчиками. Это бюджетный аналог той самой «проверяющей программы», использующий ручной труд вместо автоматизации. И, естественно, у этих разработчиков тоже есть свои ограничения. Некоторые из них плохо понимают хитроумные макросы. Поэтому их нельзя использовать. Некоторые другие вообще не знают всей кодовой базы в целом, и поэтому им не нравится код с исключениями, так как они сходу не могут понять, где и как исключение будет обработано. Им хочется смотреть в код только там, где были сделаны изменения, и чтобы сразу всё было понятно. Третьи разработчики плохо понимают С++-шаблоны, и поэтому их разрешено использовать только самым простым и очевидным способом. Так постепенно шаг за шагом формируются все эти правила. И, наверное, это правильно. Я собственно не возражаю. Единственное, меня смущает то, что этим правилам обычно приписывается некая универсальность. Якобы они имеют смысл не только в какой-то конкретной команде разработчиков, а вообще все должны их придерживаться. Типа, так код становится «более читаемым». Хочется спросить: «Читаемым кем?» А если код, например, ревьювят Александреску и разработчики boost? Почему бы не использовать шаблоны более агрессивно? Или если код ревьювит хардкорный сишник с 30-летним стажем? Почему бы не использовать сложные замороченные макросы? Ему будет приятно видеть, что кто-то ещё знает толк в извращениях. В общем, суть в том, что правила написания кода следуют непосредственно из ограничений проверяющей системы. Не важно, ручная она или автоматическая. Эти ограничения следует чётко осознавать, и тогда правила не будут выглядеть нелепо.
Разработчики становятся «некоторыми другими» даже после больничного или отпуска. А еще есть задачи, где абсолютный приоритет простоты и надежности над красотой и крутостью. Когда функция из десятка строк, (где 7 строк это проверки и обертки) лучше одной inline строки или макроса. Наважно, что в эту функцию попадет — корректное значение, некорректное или бозон Хиггса — она корректно отработает.
Простота и надёжность не противопоставлены красоте и крутости.
Это противоречие между ученым и инженером. Первый — несравним со вторым по красоте решений и крутости, но — немасштабируем (вернее, негарантированно воспроизводим в любой внешней среде, создаваемой государством).
Вторые — гарантированно воспроизводимы на уровне, скажем, не ниже четверки по профильному предмету при применении обучающего курса Х в течение Y лет.
Как и любая индустрия, космическая промышленность нуждается в определенном количестве специалистов, способных решать задачи определенного класса с качеством не ниже определенного. Дальше — теория вероятности — чем выше требования к качеству — тем меньшее количество людей статистически годны для решения задач — а значит, а) процесс становится более персонозависимым, и б) прогноз выхода специалистов нужного уровня — недостоверным
Это допустимо (и усиленно используется!) в гуманитарной области (поэты, художники итд) — но совершенно недопустимо в инженерии. Поэтому вводятся искусственные ограничения, повышающие надежность за счет снижения разрешенного множества выразительных средств — этими мерами процесс выводится из зоны персонозависимости. Снижение эффективности кода и/или красоты решения в данном случае не играют никакой роли (так как либо легко парируются техническими средствами, либо не являются метрикой качества/престижа разработчика вообще)

Уместна аналогия с переходом от аналогового к цифровому аудио — да, аналоговая запись единственна и неповторима — но она и немасштабируема! Сознательное же внесение искажений в идеал (квантование) позволяет сделать предсказуемой любую ее копию.

Параллель, проведённая между инженерами и художниками, несколько смазывается тем, что художники и поэты в гораздо большей степени, чем инженеры, ограничивают сами себя в допустимых выразительных средствах. Причём делают они это специально для того, чтобы показать свою крутость. У художников это выглядит как кубизм и супрематизм. А поэтов ограничивает необходимость соблюдать ритм и подбирать рифму. У Дэна Симмонса в Гиперионе был забавный персонаж — величайший поэт в галактике. После травмы головы у него что-то поломалось в мозгу и он мог использовать в своей речи только девять матерных слов. Много лет он был вынужден общаться, используя столь ограниченный набор слов. Но зато когда проблема исчезла и появилась возможность использовать любые слова, он с легкостью стал поэтом настолько крутым, что ему не было равных во всей галактике.
По репозиториям NASA видно, что далеко не только C/C++ используется — Phyton, Ruby, JavaScript, Java, FORTRAN и даже плагин на VB.NET к Excel.
Это всё не в боротовом компьютере.
VB.NET Excel в бортовом компьютере было бы очень забавно. =)
Интересно, а почему они более серьезные метрики кроме количества строк и ветвлений не вынесли в правила? Статический анализатор включили в правила, а метрики — нет.
Правило 0. Не использовать javascript никогда вообще никогда.
> Возвращаемое значение не-void функции должно проверяться вызываемой функцией.

вызывающей функцией

Rule 14 (checking return values)
The return value of non-void functions shall be checked or used by each
calling function, or explicitly cast to (void) if irrelevant.
В черновиках была правильная версия, в чистовик попала неправильная :-( Спасибо, исправил.
Эти десять правил не «пользователь Реддита» выжал из JPL. Их сформулировал Gerard Holzmann с коллективом в документе «The Power of 10: Rules for Developing Safety-Critical Code» в 2006 году, как раз для JPL. Они вошли в основу нынешнего стандарта, наряду с MISRA C и другими дополнениями.

Копия статьи: web.eecs.umich.edu/~imarkov/10rules.pdf
Статья в Википедии: en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Developing_Safety-Critical_Code
Большое спасибо, исправил пост и добавил вашу поправку.
Бумага, толщина: 500 листов — примерно 50 мм, 1 лист — 0,1 мм. Пусть высота 1,7 м = 1700 мм. 1700/0,1 = 17000 листов. И когда она успела столько набрать?
Миллион строк – в самый раз за несколько лет. Особенно если на ассемблере.
Там в документе всего 31 правило, кстати. Можно было бы их все перевести, остальные там тоже все make sense, десять представленные ничем особым не выделяются от общего списка. И я бы не стал называть их «жесткими». Правила, как правила. В одной организации одни, в других другие. Главное, хорошо, что они есть в принципе, и еще лучше, если им следуют.

Я думаю, что это все-таки не какие-то определенные правила «позволяют NASA писать миллионы строк кода с минимальными ошибками», а ответственность людей, которые там работают. Наличие правил и их теоретическая осмысленность не гарантируют того, что им будут следовать или применять так, как предполагалось. Скорее все-таки, это в NASA это общее понимание потенциальных последствий даже, казалось бы, маленьких ошибок, заставляет людей намного более ответственно относиться к тому, что они производят, чем в большинстве ПО общего потребления, где факапы не столько значимы.
не могли бы вы дать пруф на «миллионы строк кода»? В оригинале есть только упоминание про «hundreds of thousands of lines», что как бы на порядок меньше:)
Only those users with full accounts are able to leave comments. Log in, please.