Как оформлять алгоритмы

код должен быть самодокументируемым

launch();
ascend();
circularize();

Так толсто, что даже толсто.

Ну ладно, опустим сам процесс и результат, когда даже на винтик от ручки к сливновому бачку туалета есть целая папка документов. Welcome to aero-space, yea.

Вот тебе top 10 правил от NASA на затравку:

10 rules for developing safety-critical code

1. Restrict all code to very simple control flow constructs. Do not use GOTO statements, setjmp or longjmp constructs, or direct or indirect recursion.
2. All loops must have a fixed upper bound. It must be trivially possible for a checking tool to statically prove that a preset upper bound on the number of iterations of a loop cannot be exceeded. If the loop-bound cannot be proven statically, the rule is considered violated.
3. Do not use dynamic memory allocation after initialization.
4. No function should be longer than what can be printed on a single sheet of paper (in a standard reference format with one line per statement and one line per declaration.) Typically, this means no more than about 60 lines of code per function.
5. The assertion density of the code should average a minimum of two assertions per function. Assertions must always be side effect-free and should be defined as Boolean tests.
6. Data objects must be declared at the smallest possible level of scope.
7. Each calling function must check non-void function return values, and the validity of parameters must be checked inside each function.
8. Preprocessor use must be limited to the inclusion of header files and simple macro definitions. Token pasting, variable argument lists (ellipses), and recursive macro calls are not allowed.
9. The use of pointers should be restricted. Specifically, no more than one level of dereferencing is allowed. Pointer dereference operations may not be hidden in macro definitions or inside typedef declarations. Function pointers are not permitted.
10. All code must be compiled, from the first day of development, with all compiler warnings enabled at the compiler’s most pedantic setting. All code must compile with these setting without any warnings. All code must be checked daily with at least one—but preferably more than one—state-of-the-art static source code analyzer, and should pass the analyses with zero warnings.

Ну и дальше по тексту:

• http://pixelscommander.com/wp-content/uploads/2014/12/P10.pdf
• https://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf
• http://homepages.inf.ed.ac.uk/dts/pm/Papers/nasa-c-style.pdf

В российской космической программе «Буран» используется ДРАКОН

Единая система программной документации (ЕСПД)

no more than one level of dereferencing is allowed

Жесть!

Function pointers are not permitted.

Я так понимаю, что у них все программы на конечных автоматах...

Д.Р.А.К.О.Н. Уже предлагали?

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

По ГОСТ 19.701-90

Literate programming? Ну или что-то в этом стиле. Наверное, для нового и нетривиального алгоритма, одно его описание должно быть достаточно для реализации алгоритма с нуля. Поэтому может иметь смысл описать в отдельном документе и сослаться в коде на него.

ЕСПД в помощь.

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

Если не про рокет сайнс, а про земной бизнес, то обычно есть внутренняя wiki, там вся дока, спеки, ТЗ, алгоритмы псевдокодом и диаграммами.

UML State Machine / UML Activity.