I have been reading a book about programming correctness and robustness and attempting to assure the coder of that. The main concepts that it discussed were preconditions, postconditions, invariants, assertions, and penalties. I am concerned that I am not optimally using these things.

It is clear that preconditions do not cause much overhead with the assessment for them. They generally are null checks with conditionals. There are different philosophies about this: https://stackoverflow.com/questions/315306/is-if-expensive. However, postconditions may not be easily verified unless we have a simple enough method, if we are looking at methods or functions that have one single responsibility. We would commonly use assertions to test postconditions. Checking invariants, though, can be costly. Should we? It really depends on whether we want things to be deterministic outside the method or function. We definitely want less coupling. However, verifying whether the invariance happens is costly. We should not test for invariance most of the time because it is so costly to performance and even maintenance. It would make the method or function very unintuitive to read.

Generally, I have found that writing out exactly what these conditions are in the method summaries is helpful. But, it is something that is brushed over by most programmers. Therefore, I think that the summary should only be emphasized when absolutely necessary.

Also, if we truly want to use contracts with interfaces, doesn't it make sense to take the contracts seriously if we indeed want to genuinely use them? It would definitely help with development at the time of writing and at the time of extending classes.

At my job, as we go forward to creating new systems, like a new web application we are thinking about doing, it is important to take this design considerations under scrutiny. They really help in true engineering to make a fail proof system. This especially true if we are going to be doing Test Driven Development.