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