An Engineering daybook is a way to compile quick notes on a given day to help recall info that you want to always remember. The purpose of these notes is to share my “aha!” moments in quick articles which will be “duh!” moments for most, but hopefully helpful for others.
A company I worked for in the past had some code that had been around since the company started. In some of this code I noticed something interesting (an “old” practice, at least I thought).
My first thought was wow, I haven’t seen assertions outside of tests in a while. My second thought was who puts asserts in the code past debugging? My last thought was, that scenario they are asserting would never happen.
I kind of glanced over those thoughts and left the asserts intact. And I’m glad I did.
Fast forward to last nights re-reading of chapter 4 (Pragmatic Paranoia) of The Pragmatic Programmer. I came across Tip 39: Use Assertions to Prevent the Impossible.
The very assertions that I were questioning the necessity of, provide an easy means to give feedback on a contract violation to a pre condition(see Design By Contract). They provide a code feedback loop for things that otherwise could bring down an application in production.
I’m pretty excited to start using asserts within my code. Has anyone else has made this a practice? And if you have , have you found it to be useful to fail fast especially when trying to adhere to Design by Contract?
If you enjoyed reading this, consider giving me a follow -> Follow Me