eGospodarka.pl

eGospodarka.plGrupypl.comp.programming › Jak to robią w NASA
Ilość wypowiedzi w tym wątku: 87

  • 1. Data: 2019-08-30 09:09:43
    Temat: Jak to robią w NASA
    Od: Roman Tyczka <n...@b...no>


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

    --
    pozdrawiam
    Roman Tyczka


  • 2. Data: 2019-08-30 09:20:10
    Temat: Re: Jak to robią w NASA
    Od: Mateusz Viste <m...@w...tell>

    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


  • 3. Data: 2019-08-30 10:06:33
    Temat: Re: Jak to robią w NASA
    Od: q...@t...no1 (Queequeg)

    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


  • 4. Data: 2019-08-30 12:27:37
    Temat: Re: Jak to robią w NASA
    Od: Roman Tyczka <n...@b...no>

    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


  • 5. Data: 2019-08-30 13:09:14
    Temat: Re: Jak to robią w NASA
    Od: Mateusz Viste <m...@w...tell>

    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


  • 6. Data: 2019-08-30 14:49:10
    Temat: Re: Jak to robią w NASA
    Od: Mateusz Viste <m...@w...tell>

    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


  • 7. Data: 2019-08-30 19:20:34
    Temat: Re: Jak to robią w NASA
    Od: Adam Klobukowski <a...@g...com>

    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


  • 8. Data: 2019-08-30 19:21:44
    Temat: Re: Jak to robią w NASA
    Od: Wojciech Muła <w...@g...com>

    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.


  • 9. Data: 2019-08-31 22:14:53
    Temat: Re: Jak to robią w NASA
    Od: "M.M." <m...@g...com>

    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


  • 10. Data: 2019-08-31 22:54:12
    Temat: Re: Jak to robią w NASA
    Od: "M.M." <m...@g...com>

    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


strony : [ 1 ] . 2 ... 9



Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: