Comments by "MrAbrazildo" (@MrAbrazildo) on "how my programming changed after 20 years" video.

  1. 1:54, yeah, this is really good strategy. The only issue is when working with a team: others might not have your concern towards safety, prefering to rely on their intuition. So, it's a good idea to shrink the verifying code. 4:00, if possible, an interesting way of doing this would be to pack errors as flags of a bits mask: a unique number for each of these errors. When any of them happens, it'd be recorded as the positive Nth-bit. So the asserts would always look the same, something like: assert_stats (blablabla). The f() would check all errors at once, since bits work in parallel, taking less than a machine cycle. Like (in C): if (Mask & (DUMMY_CLIENT | EXPECTED_CONNECTION | COULD_NOT /*blabla*/) == 0) return true; // All ok. Otherwise, switch-like below, for error messages. Only if an issue matches, it'd make a detailed switch-like process, with error messages. So it'd "feel easy" for anyone to just call the same thing, not dealing with different err messages at each call, for instance. C macros could even hide this into the f()s beginning: instead of {, write BEGIN, which would put { and call assert_stats behind the scenes. Later it could be as easily disabled, by just editing the macro definition.
    1