[bunderbunder]

I do wonder if sometimes these things are set up as false dilemmas, though.

I skimmed through NASA’s coding manual a while back, and one of the things that I took away from it was that optimizing for readability is optimizing for safety.

It’s just that it’s hard for me to see it as readability because I’m not familiar with the problem domain. For example, their ban on reentrancy would definitely require me to rewire my brain a bit. But, for what they are doing, that is a readability decision: they needed to be able to guarantee that a spacecraft’s firmware couldn’t experience a stack overflow, and reentrant code makes it much harder to reason about stack growth.

[po1nt]

Removing null pointer guards would improve readability, not safety. Removing hashing on passwords would also improve readability and made the program easier to debug.

[bunderbunder]

That feels like a strawman to me? Both of those are examples of simply not implementing functional requirements, which is never ok.

For storing passwords in the clear, that should be obvious.

For null checks it may be more subtle, but consider the case of languages like Rust and Kotlin that let you eliminate null checks and replace them with static guarantees that a reference won’t be null. In noth cases that’s celebrated as a win for both safety and readability. So I’m inferring an unstated major premise that we’re talking about skipping null checks in functions where null cannot be formally eliminated from the function’s input domain. (Maybe we’re working in Java instead.) In which case I must insist that null checks are good for readability because they explicitly communicate important information about what arguments the function is willing to accept. It’s leaving that important information unstated and implicit that would be bad for readability.

[po1nt]

Safety is almost never functional requirement (unless for OpenSSL and such projects). You can always focus just on the happy path expecting users will behave. Even in Rust you can unwrap on unexpected value instead of handling it properly. It will lower the LoC, thus increasing readability but possibly crashing the program on unexpected inputs. Possibly leaving open doors for DoS where attacker would just spam invalid input and crashing the server.