On Friday, August 30, 2019 at 9:20:11 AM UTC+2, Mateusz Viste wrote:
> 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"

To jest zalecenie wydane przez Dijkstrę w epoce fortrana łupanego.
Podstawa programowania strukturalnego i pochodnych.

> "No function longer than 60 lines of code"

Akurat dość dobre, z gatunku czytelności kodu.
Jesne, jeśli akurat wyjdzie 70 linii niepodzielnego kodu
(jakaś procedura numeryczna) to nie jest to zbrodnia.

> "Do not use dynamic memory"

"... after inicjaization". Możesz zaalokować tyle, ile trzeba.
Nie baw się jednak np w dynamicznei rosnącą tablicę.

To jest specyfika dziedziny. Dość częste zalecenie tam,
gdzie rzeczy mają być niezawodne, wiec deterministyczne.
Ale tylko do tych specjalistycznych zastosowań.

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

Ogolnie, wszystkie zalecenia to albo estetyka, albo ograniczenie
dostępnych klocków, aby bylo prościej.
Dziwi mnie rekurencja wsadzona w wzięte z assembleera setjump i longjump.
O ile te ostatenie, razem z goto psują programowania strukturalne,
utrudniają analizę kodu i są zwalczane od kilkudziesiaciu lat,
to co tam robi rekurencja.
Jesne, rozumiem związane z nią "zagrożenia", na poziomie, gdzie wymagają
dowodliwego ograniczenie na liczbę obrotów pętli, można się bać nieskończonej
rekursji czy skonczenia stosu. Ale to inna kategoria niż goto;-)
Wywalenie rekurencji pośrednio mocno ogranicza dostępne struktury danych.
Drzewa pisze się znacznie gorzej. Ale znow, to do krytycznych fragmentow
kodu.


pzdr
bartekltg