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

--
pozdrawiam
Roman Tyczka

do góry

On Fri, 30 Aug 2019 09:09:43 +0200, Roman Tyczka wrote:
> https://fossbytes.com/nasa-coding-programming-rules-
critical/

To raczej ciekawostka, bo do normalnego życia ma się nijak - NASA to
jednak dewianci są. :)

"Do not use goto"
"Do not use dynamic memory"
"No function longer than 60 lines of code"

Żadne z powyższych do mnie nie przemawia, ale oczywiście gdybym pisał
programy sterujące rakietami ziemia-jupiter to na pewno też miałbym
stracha.

Mateusz

do góry

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

do góry

On 30 Aug 2019 07:20:10 GMT, Mateusz Viste wrote:

>> https://fossbytes.com/nasa-coding-programming-rules-
critical/
>
> To raczej ciekawostka, bo do normalnego życia ma się nijak - NASA to
> jednak dewianci są. :)
>
> "Do not use goto"
> "Do not use dynamic memory"
> "No function longer than 60 lines of code"
>
> Żadne z powyższych do mnie nie przemawia, ale oczywiście gdybym pisał
> programy sterujące rakietami ziemia-jupiter to na pewno też miałbym
> stracha.

Co prawda nie piszę w C, ale pierwszego i trzeciego warunku też
przestrzegam i nikt mi tego nie narzuca, to po prostu pomaga.
A metody dłuższe niż kilkadziesiąt linii to zmora.

--
pozdrawiam
Roman Tyczka

do góry

On Fri, 30 Aug 2019 12:27:37 +0200, Roman Tyczka wrote:
> Co prawda nie piszę w C, ale pierwszego i trzeciego warunku też
> przestrzegam i nikt mi tego nie narzuca, to po prostu pomaga.
> A metody dłuższe niż kilkadziesiąt linii to zmora.

W ogólnym i teoretycznym przypadku - zgadzam się.

W praktyce bywa jednak że trzymanie się takich sztywnych zasad "bo tak"
sprawia tylko kłopot. Przykład z głowy: funkcja która wykonuje dużą ilość
sekwencyjnych kroków konfiguracyjnych czegoś tam. Dzielenie jej na siłę
niekoniecznie jest racjonalne.
Z goto podobnie: w 95% przypadków goto można z zyskiem zastąpić inną
konstrukcją, ale zostaje te 5% czasu kiedy GOTO sensownie załatwia temat
a jakieś wymyślanie pętli/funkcji/czegoś to tylko cudowanie dla sztuki
niemania goto.


/* init thermonuclear engine, returns ptr on success, NULL otherwise */
void *engine_init(void) {
void *p = NULL;

p = malloc(ENGINE_MEMSZ);
if (p == NULL) goto SHITHAPPENS;
engine_prepare(p);
engine_thermonuclear_start(p);

if (rs232_init(COM_BAUDRATE) != 0) goto SHITHAPPENS;
if (is_it_friday_afternoon() != 0) goto SHITHAPPENS

return(p);

SHITHAPPENS: /* smth went south, cleanup and return NULL */
if (p != NULL) engine_thermonuclear_abort(p);
free(p);
rs232_close();

return(NULL);
}


Powyższe można wykonać na kilka sposobów, i nie ma problemu pozbyć się
goto - tylko po co? Gdyby ktoś z jakichś swoich powodów zakazał mi goto,
to opakowałbym całość w do { ... } while(0) i zamiast goto korzystał z
break - ale to tylko dodatkowa gmatwanina, wcale nie czytelniejsza.

Mateusz

do góry

On Fri, 30 Aug 2019 08:06:33 +0000, Queequeg wrote:
> 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ę.

Czekaj czekaj, ale większość programów to jedna niekończąca się pętla.

for (;;) {
wait_input();
do_job();
}

Czy ja czegoś nie rozumiem, czy ta reguła zabrania takich konstrukcji? A
jeśli zabrania, to jak inaczej? Przecież goto też zabraniają. :)

> 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ć :(

Logika jest - ale chyba tylko w lotach kosmicznych albo innych
przemysłowych dziedzinach, gdzie nic nie ma prawa się nie udać. W
praktyce program graficzny będzie alokował pamięć zależnie od tego,
jakich rozmiarów dostał plik graficzny do załadowania. Jak user ma mało
pamięci to i tak może sobie pomalować w 640x480, a przy większych
bitmapach dostanie zonk.

> 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.

if (printf("Hello") != 5) NO_I_CO_MAM_ZROBIC();

Ciekawe jaki mają procent zachorowań na depresję wśród programistów. :)

Mateusz

do góry

W dniu piątek, 30 sierpnia 2019 10:06:36 UTC+2 użytkownik Queequeg napisał:

> 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.

> 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ć :(

Te reguły wynikają z tego że to jest praktycznie programowanie embeded/raw
metal/realtime. Pamięci mało, stosu mało, często nie ma dynamicznej alokacji i kod
nie może rzucić błędem 'bo się alokacja nie udała' tylko musi być tak napisany żeby
mieć gwarancję że potrzeby dotyczące pamięci zawsze będą spełnione.

AdamK

do góry

On Friday, August 30, 2019 at 9:10:03 AM UTC+2, Roman Tyczka wrote:
> https://fossbytes.com/nasa-coding-programming-rules-
critical/

Bardzo polecam ten artykuł: https://www.fastcompany.com/28121/they-write-right-s
tuff

BTW "All code must be compiled, from the first day of development, with all compiler
warnings enabled at the compiler's most pedantic setting." używamy, polecam (-Werror
jest, wbrew pozorom, wicej niż korzystne)

w.

do góry

On Friday, August 30, 2019 at 2:49:11 PM UTC+2, Mateusz Viste wrote:
> On Fri, 30 Aug 2019 08:06:33 +0000, Queequeg wrote:
> > 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ę.
>
> Czekaj czekaj, ale większość programów to jedna niekończąca się pętla.
>
> for (;;) {
> wait_input();
> do_job();
> }
>
> Czy ja czegoś nie rozumiem, czy ta reguła zabrania takich konstrukcji? A
> jeśli zabrania, to jak inaczej? Przecież goto też zabraniają. :)
>
> > 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ć :(
>
> Logika jest - ale chyba tylko w lotach kosmicznych albo innych
> przemysłowych dziedzinach, gdzie nic nie ma prawa się nie udać. W
> praktyce program graficzny będzie alokował pamięć zależnie od tego,
> jakich rozmiarów dostał plik graficzny do załadowania. Jak user ma mało
> pamięci to i tak może sobie pomalować w 640x480, a przy większych
> bitmapach dostanie zonk.

To też można różnie rozumieć. Może używanie bibliotecznych wektorów, list,
zbiorów, itd nie jest dynamicznym allokowaniem pamięci (po inicjacji)?


>
> > 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.
>
> if (printf("Hello") != 5) NO_I_CO_MAM_ZROBIC();
>
> Ciekawe jaki mają procent zachorowań na depresję wśród programistów. :)

Bez kontekstu można powiedzieć, że powinien zapisać w pliku logu że doszło do
takiej sytuacji, żeby programista szybciej zaczął się zastanawiać nad
przyczyną problemu.

A tak poza tym, dużo softu ma bezpośredni wpływ na życie, zdrowie, pieniądze;
jeszcze więcej softu ma pośredni wpływ na ważne sfery życia. Nic dziwnego
że próbuje się podawać skrótowy zestaw reguł pomagający niezbyt zaawansowanym
programistom tworzyć bezpieczny kod. Natomiast kompulsywne trzymanie się
dowolnych skrótowych reguł, zwłaszcza bez dobrych intencji, oczywiście/zawsze
źle się kończy, np. depresją programistów.

Pozdrawiam

do góry

On Saturday, August 31, 2019 at 10:44:23 PM UTC+2, slawek wrote:
> "M.M." <...@...c> Wrote in message:
> > Nic dziwnego że próbuje się podawać skrótowy zestaw reguł pomagający niezbyt
zaawansowanymprogramistom tworzyć bezpieczny kod.
>
>
> Nic dziwnego.
>
> Tyle że cytowane (link) regułki to takie raczej mało poważne jest.
> No i to nie jest gdzieś tam na serwerze NASA, tylko jakiś
> blogasek kogoś o kim - szczerze - pierwsze słyszę. Autorytet z
> niego taki jak z Piotrusia z IIIc.
>
> Więc nie łykałbym tego niczym młody pelikan. Także dlatego że
> trochę takich manifestów czytałem.

W ogóle każdy krótki tekst na temat ogólnych wytycznych w
tworzeniu krytycznych dla zdrowia, życia i pieniędzy systemów jest
mało poważny. Natomiast racje Ci przyznam, że poważniej by było,
gdyby autor dany esej wyprodukował, sprawdził jak zostanie zrozumiany,
skojarzony, oceniony; następnie poprawił i znowu poddał krytyce, dopiero
potem by opublikował. Za trzecim razem powinny zniknąć dwuznaczności,
czy allokowanie za pośrednictwem vector, też jest dynamicznym allokowaniem.
Racja też, że w NASA mają środki takie weryfikowanie i poprawianie.

Pozdrawiam

do góry