Roman Tyczka <n...@b...no> wrote:

> https://fossbytes.com/nasa-coding-programming-rules-
critical/

To lecimy.

1. Restrict all code to very simple control flow constructs - do not use
goto statements, setjmp or longjmp constructs, and direct or indirect
recursion.

Z setjmp/longjmp się zgodzę. goto przydaje się w C, gdzie nie masz RAII i
chcesz wyczyścić zasoby, i IMO tylko w takim przypadku jest uzasadnione.

Rekurencja... czasem prościej jest zrobić coś rekurencją niż iteracją,
choć każdą rekurencję i tak można zamienić na iterację, a sama rekurencja
nie jest zła. Jest zła wtedy, kiedy wymyka się spod kontroli. Wszystko
zależy od konkretnej sytuacji.

2. All loops must have a fixed upper-bound. It must be trivially possible
for a checking tool to prove statically 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.

Zgadzam się.

3. Do not use dynamic memory allocation after initialization.

Znów... zależy od konkretnego zastosowania. MISRA C zresztą mówi to samo.
Widzę w tym logikę, ale nie chciałbym tak pisać :(

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.

Zgoda. Zbyt długie i rozbudowane funkcje to rak. Natomiast znów... jestem
sobie w stanie wyobrazić wyjątki.

5. The assertion density of the code should average to a minimum of two
assertions per function. Assertions are used to check for anomalous
conditions that should never happen in real-life executions. Assertions
must always be side-effect free and should be defined as Boolean tests.
When an assertion fails, an explicit recovery action must be taken, e.g.,
by returning an error condition to the caller of the function that
executes the failing assertion. Any assertion for which a static checking
tool can prove that it can never fail or never hold violates this rule
(I.e., it is not possible to satisfy the rule by adding unhelpful
assert(true) statements).

Zgadzam się odnośnie używania asercji, mój kod też jest zwykle nimi
najeżony. Nie podoba mi się sztuczne narzucanie "assertion density".
Asercje powinny być używane tam, gdzie są potrzebne, a nie sztucznie, żeby
osiągnąć minimum dwie asercje na funkcję. Nie podoba mi się też explicit
recovery action, choć jeśli dopuszczają wyjątki (a skoro piszą w C to nie
dopuszczają, bo jak?), to jestem w stanie to przełknąć.

6. Data objects must be declared at the smallest possible level of scope.

Zgoda.

7. The return value of non-void functions must be checked by each calling
function, and the validity of parameters must be checked inside each
function.

Tu znów odbijamy się od tego, czy to są sztywne zasady, które trzeba
stosować, czy zbiór sugestii. Są funkcje, których wartość zwracaną celowo
ignorujemy, bo flow programu nie różni się w zależności od zwróconej
wartości (wartość zwrócona jest tylko dodatkową informacją, która może,
ale nie musi, być użyta).

8. The use of the preprocessor 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. All macros must
expand into complete syntactic units. The use of conditional compilation
directives is often also dubious, but cannot always be avoided. This means
that there should rarely be justification for more than one or two
conditional compilation directives even in large software development
efforts, beyond the standard boilerplate that avoids multiple inclusion of
the same header file. Each such use should be flagged by a tool-based
checker and justified in the code.

Po części zgoda, bo preprocesor jest tylko parserem tekstu, ale po części
nie. W czym im przeszkadzają elipsy? Co do warunkowej kompilacji -- w
sumie zgoda.

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.

Jestem w stanie znaleźć uzasadnienie, ale znów -- to programista odpowiada
za to, żeby wskaźniki były użyte prawidłowo. Ciekawe też, czemu wskaźniki
do funkcji nie są dozwolone.

10. All code must be compiled, from the first day of development, with all
compiler warnings enabled at the compilers 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.

Tu zgoda w 100%.

Ogólnie... nie chciałbym pracować w środowisku, w którym są sztywno
narzucone takie zasady. To powinny być zalecenia a nie sztywne reguły.

--
https://www.youtube.com/watch?v=9lSzL1DqQn0