why not?
http://www.rankred.com/nasa-coding-rules/
any other org/company coding rules?
Why is there not a women on that picture?
>>60008623
DELET
>>60008382
No large functions is particularly interesting to me and a particularly easy rule to break.
It would likely require constantly breaking larger functions into smaller ones as development progresses, but I think would ultimately make for code that is much easier to debug and understand.
>>60008382
feels like coding for an arduino
>>60008382
Some of the rules are good.
Some of the rules are good only for mission critical software.
>>60008382
Yeah, this government contractor I work for follows most of the rules NASA employs.
>>60008382
>Do not use ... direct or indirect recursion.
I understand the reasoning but I disagree. Because of that you can't have any recursive data structure, not even a linked list or a tree, or anything that contains a recursive part.
>No Dynamic Memory Allocation
That sounds difficult. I'd be interested to know how to work without dynamic memory at all.
>>60008382
>#define assert
fucking cancer
>>60008832
Recursive data structures can and should be implemented iteratively, performance for recursion is pretty bad.
>>60008832
>No Dynamic Memory Allocation
this is a matter of things that are mission critical
imagine you die because pajeet didn't wanna deal with checking everything and thought 'well the garbage collector will clean up anything I fucked up so its fine'
>C
no wonder they're not getting shit done
>>60008877
You should be using a compiler/language that can and does support tail call optimization. Thinking for iterative is pretty restricted.
>>60008832
>I'd be interested to know how to work without dynamic memory at all.
No heap, registers & stack only, Final Destination.
>>60008916
No it's not, if the data structure can't be implemented iteratively, you shouldn't be using it anyways.
>>60008382
>No Code of Conduct
trash
>>60009177
People like you are why we're still fucking stuck with ALGOL-derived languages for high level programming when it's fucking retarded.
>>60008906
NASA has an insanely good record compared to the other space agencies when it comes to success of outer solar system probes. NASA has not failed a mission to the outer solar system in nearly a decade
>>60008906
the reason they don't actually get shit done is the fact that they depend on government funding
>>60008382
>why not?
Because I don't work at NASA.
>>60010900
why don't you work at NASA anon? Are you not smart enough?
>>60012537
me neither
>>60009248
I really wish normies had never gotten into computing.
>>60013041
they still aren't, they are just the retards at jobs where you come in and fix everything they've touched, replace all their code, and then leave. They are the ones who make endless documentation changes on github, code style changes, and push for codes of conduct while never fixing anything or adding new features beyond visuals.
>>60009785
Found the cocky CS guy who wants everyone to spend decades trying to decipher his Haskell cause he wrote it and it must be good.
You think NASA lets CS majors write code for them?
I heard engineers program like retards and their style and form are shit
>>60008573
https://google.github.io/styleguide/cppguide.html
>>60015210
>indent with 2 spaces
>} else {
>>60008382
>why not?
Most of their rules are sound and make sense. However,
>Rule No. 3 – No Dynamic Memory Allocation
This is a sound rule when you make mission critical code for embedded systems being shot into space that needs to be verified and proven correct, but it's not sound as a global rule.
>Rule No. 4 – No Large Functions
Not even Linux would pass this one, it's pretty common in Linux with large functions. The TCP output engine, for example, has a function that's over 1500 lines long.
However, in general, this rule is sound and should be followed.
>>60008382
Seems good. Especially the short functions.
>>60016021
Linux isn't exactly a pristine example.
>>60016214
No, but I used it as an example because it's frequently used on embedded platforms.