6 Don’t surprise your users

 

This chapter covers

  • The Principle of Least Astonishment and not surprising your users
  • Preventing surprisingly poor runtime performance
  • Careful coding with C++ vectors to avoid performance problems
  • Applying Programming by Contract to a class and its member functions

We all love surprise parties but being surprised by the results of a function call is a definite sign of poor design. Well-designed software should not contain any surprises that can cause runtime logic errors or poor performance.

Ideally, when we design a class, its objects will behave and perform just as its users expect. A user can be another programmer who uses the class, or an end user who interacts with the application. Unexpected behavior can cause runtime logic errors or applications that don’t perform well.

6.1 No surprises and the Principle of Least Astonishment

6.1.1 Off-by-one errors

6.1.2 Misnamed functions can mislead their callers

6.2 Poor performance is an unwelcome surprise

6.2.1 Bad design can cause unexpected performance problems

6.2.2 The vexatious performance of C++ vectors

6.3 Programming by contract helps to eliminate surprises [OPTIONAL]

6.3.1 Programming a circular buffer by contract

6.3.2 Precondition: what must be true before calling a function

6.3.3 Postcondition: what must be true after returning from a function

6.3.4 Class invariant: what must remain true of object states

6.4 Summary

sitemap