> I'll grant OP a Magic Cloak of Error Abolishment and an enchanted ring with +4 INT, +4 WIS, and +3 VARIABLE-NAMING... Most of those come from my test suite.

> I'll grant OP a Magic Cloak of Error Abolishment and an enchanted ring with +4 INT, +4 WIS, and +3 VARIABLE-NAMING... Most of those come from my test suite. Without that, I'm back to -2 INT, -3 WIS, and a Cursed Cloak of Mistakes. I did let some bugs slip through the first time around… > what's the very first thing I'm gonna do when I inherit his project for support or further development? Start ripping it apart to add tests so that I can verify the behaviour of the system pre, and post, change. As far as Monocypher is concerned, I already did that. Test vectors, property based test, sanitisers, code coverage analysis, the works. The public interface is testable enough that you don't need to take apart anything to thoroughly test that library (it already is). Huge help with "making positive changes to the code within hours". This change to Blake2b for instance took me a few minutes to make and verify. https://github.com/LoupVaillant/Monocypher/commit/80ebf55307f689390d41c3c48eaeab157519bc7f https://github.com/LoupVaillant/Monocypher/commit/80ebf55307... > A strong feeling that something is "bug-free" does not tell me that everything works unchanged on a new platform/OS/architecture, or let me throw in a newly conceived corner case, or check some environmental oddity... It helps that Monocypher has zero dependency (not even the standard library), uses fixed size integers almost exclusively, compiles without warning as C and C++ with GCC and Clang, and that crypto code is abnormally straight line. > If we start out with the premise that systems spend most of their lifetime in maintenance I made sure Monocypher required next to no maintenance (I won't have the time for significant maintenance work). It's mostly a matter of size and scope.