Skill builder: How To Code Like NASA

[bartzrt]

One addendum on readability: "someone else" is also you, six months from now.

[CalebKraftmakes]

This is fantastic Allyson! Welcome to the channel!

[johnreynolds]

I have written bottom-level procedures and routines that were forty lines of documentation for six lines of executable code. Because I knew that I would have no idea what was going on when I had to go back into those routines, months down the line, and a couple of 'Hey idiot' comments saved me hours of "What the heck was I thinking?" JPL forever!

[woodstein]

Amazing! I'm going to try to integrate this into my own coding.

[MikeSenese]

The future is in good hands. Great tips, Allyson.

[toddsotkiewicz]

Good solid reminders for me to keep in mind. Thanks.

[mannibimmel]

the reminder is always welcome) thanks

[cathyshanahan]

Some great tips here Allyson, thank you!

[TimTeatro]

First off: thanks and thumbs-up. Friendly critique: at 2:30 (rule 5) your interpretation of this rule is good advice (yes, always unit testing) but I don't think it's consistent with what the aim of the rule. Unit tests cannot replace assertions. Assertions are predicates that allow us to test, at minimum, the function interface boundaries. That is, the arguments and return values. (Assertions in the body are good too.) Unit tests will only test the behaviour of the function, while assertions can test the behaviour of the caller as well. If I have `foo: int32 → int32`, but `foo` should only be called with arguments in the range [-5, 5], then the code will happily compile (because the signature is a lie) and you can unknowingly violate its interface constraint. Unit testing that function won't help because the bug isn't in the function, it's in the caller. The bug should arise later, during integration or system tests. If those tests trigger an assertion failure, I know what went wrong and where. Otherwise, the test tells me my system is misbehaving but it could take days in a debugger to figure out where or why.

[Rolandd]

Good idea. Now I'm thinking about expanding the idea to other projects and writings.

BTW: I think Alyson meant to say NASA started in 1958, not 1985.

[dvsm]

Great.Thanks for the information. Love from India🇮🇳.

[nickroe]

Thank you, very helpful and brief ideas on good code standards.

[DaTnkee]

Basically it is Clean Code from Uncle Bob.

[KevinArellano]

It's my dream to work in JPL. I wonder how long it'll take XD

[firstname]

hey NASA, don't forget the metric to imperial conversion !

[lechurrajo]

I don't agree with relating assertions with unit test. Assertions are their own thing, are very useful (easier to write and can catch multiple different errors on various runs) and for some reason ignored in modern 'best practices'

[wanderingfido]

Doesn't 'coding like NASA' mean I should become wilfully confused about units of measurement? And liberally interchange them instead of including a shared and centralized /usr/src/limits.conf? just wonderin'. For a friend. 🤔😏

[triton_princeofatlantis]

when youre a software dev a nasa and didnt know there is a standard and use C#

[NoxmilesDe]

Use miles!
No, use kilometers!
Damn, these standards

[ifiokedemidiong]

Why is every female engineer so pretty