100 Tips from The Pragmatic Programmers Book: Part 4/10

Rajesh Royal - Jan 28 - - Dev Community

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 😀

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Terabox Video Player