4.1. Failing Test Before Fixing Code.
Create a focussed test that reveals the bug before you try fixing it.
ย
4.2. Read the Damn Error Message.
Most exceptions tell both what failed and where it failed. If youโre lucky you might even get parameter values.
ย
4.3. โselectโ Isn’t Broken.
It is rare to find a bug in the OS or the compiler, or even a third-party product or library. The bug is most likely in the application.
ย
4.4. Donโt Assume ItโProve It.
Prove your assumptions in the actual environmentโwith real data and boundary conditions.
ย
4.5. Learn a Text Manipulation Language.
You spend a large part of each day working with text. Why not have the computer do some of it for you?
ย
4.6. You Canโt Write Perfect Software.
Software canโt be perfect. Protect your code and users from the inevitable errors.
ย
4.7. Design with Contracts.
Use contracts to document and verify that code does no more and no less than it claims to do.
ย
4.8. Crash Early.
A dead program normally does a lot less damage than a crippled one.
ย
4.9. Use Assertions to Prevent the Impossible.
If it canโt happen, use assertions to ensure that it wonโt. Assertions validate your assumptions. Use them to protect your code from an uncertain world.
ย
4.10. Finish What You Start.
Where possible, the function or object that allocates a resource should be responsible for deallocating it.
ย
Thanks for reading, happy coding ๐
