Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I've just started informatics university and I'm attending a programming course about C(++). The programming professor prefers to connect every topic with a type of programming design that is similar to Design by Contract. Basically, what he asks us to do is to write every exercise with comments that denote the pre-condition, post-condition, and invariants that should prove the correctness of each program we write.

But this doesn't make any sense to me. Maybe writing down your thoughts prevent you from making some mistakes, but if this is all an abstract thing, then if your program intuition is wrong, you'll write your program wrong, and then you'll also write pre and post conditions wrong. In the end, you'll be convinced that a wrong program might actually be correct.

I had some programming experience before this course and I found myself comfortably with just writing a program and unit testing it. It takes less time to accomplish and is less "abstract" than just thinking about what every single piece of your program should do in every case (which is kinda like mentally testing it).

Finally, determining the pre and post conditions takes me about 80% of the total time of the exercises. It's harder to think about putting down this pre and post correct than to write the program itself.

Am I right in thinking that working with pre-conditions, post-conditions, and invariants aren't worth anything? Should I convince myself that this method is right?

share|improve this question
Hmm. It sounds like you think pre and post conditions are completely disconnected from testing. They aren't. Think of pre-conditions as the inputs to your test (or the setup state) and post-conditions as the outputs of your test (or the things to be asserted). Why do you think pre/post conditions are different from the testing aspect of "just writing a program and unit test it"? –  Peter K. Mar 21 '12 at 13:46
C and C++ are extremely different languages. There is no such thing as C(++). –  DeadMG Mar 21 '12 at 14:30
@DeadMG, we are doing C++ but not the plus-plus part (classes and stuff)... –  Jefffrey Mar 21 '12 at 14:32
@Charlie: That's not really C++, then, it's C you've compiled with a C++ compiler. –  DeadMG Mar 21 '12 at 14:43
It isn't design by contract, it is Hoare logic en.wikipedia.org/wiki/Hoare_logic It is the first step to axiomatic semantics, and the formal verification of program correctness. –  stonemetal Mar 22 '12 at 19:01
add comment

5 Answers

up vote 9 down vote accepted

When I tested out of my Java course, my professor was much the same way; 90% of the project was developing a flow chart and writing pseudo code, and the actual program took no more than a few hours to write.

Since then however, I have been writing down my processes more and more... not by any particular method or anything, but just figuring out all the angles of my end program. I feel like it has saved time in the long run.

When I first started programming, I didn't need to do all the overhead, because the programs I made were trivial. So, I was in the same boat as you: "Why are we wasting time doing all of this?"

Once you start working on larger productions, possibly with some help on the side, having a plan in plain english will be more beneficial than writing several dozen lines of code only to change your mind an hour later.

So, I wouldn't condone what your professor is teaching you, though for an intro class it is indeed rather pointless. With large and more obscure projects, writing out the plan of action is helpful. Who knows, you could be working for a pointy-haired boss someday that needs to know what you're trying to do and doesn't speak C++.

Lastly, don't think that the way you're being taught to plan out your code is the only way to do it. Planning methods are just tools like the programming languages they assist.

share|improve this answer
Dang - I was going to write the same answer. ;-) I think you should change the phrase "simple enough not to need it" to "trivial." Homework assignments are generally tiny - they don't require the writing of requirements, specs and plans. However, the programmer needs to learn those skills. If they aren't well motivated, that may be a professor problem. –  Bob Cross Mar 21 '12 at 14:14
The benefit of having a plan printed out is that you get to go 'I love it when a plan comes together' and light up a big cigar at the end of a project. –  mcfinnigan Mar 21 '12 at 14:42
I may have read over this, but "design by contract" with its preconditions and such is a computer evaluatable mechanism and not a means of planning ahead in plain English. For the latter I would surely use a different tool. –  Legolas Mar 22 '12 at 6:59
add comment

if your program intuition is wrong you'll write your program wrong

Yup. This is the way the world is.

When I was a lad we were taught to think about how our program would work, to split it into manageable parts, and to think about how those parts would fit together. Then write these thoughts down so you wouldn't forget them. And then, you could write your program and it'd be bug-free and work correctly. At the time a lot of people programmed by sitting down and start typing, which gave dreadful results, but they got the instant gratification we desire.

So, here you're being taught to think first, code second. That the code is almost irrelevant when compared to the overall design. These things are true, these things will make you a much better programmer. You'll notice this when you leave university and have to start working on real-world applications,the ones that make your uni coursework look like mickey-mouse apps. The ones where you are no longer working with a thousand lines of code, but several million lines. Then you'll understand exactly why you need to think hard before setting finger to keyboard.

Most of the time, both me and other students have written programs that seemed ok and that had correct pre and post condition too. But at the moment of testing it was just completely wrong.

Yes, this is why he's making you do it - if you cannot think how to write a correct program, how do you expect to be able to, well, write correct programs? You can write it iteratively using a code-test-fixbugs-code-test-fixbugs approach, which is fine for small stuff, but again, get a big project and you'll spend a impressive amount of time getting it to work right.

share|improve this answer
+1: I think programming consists of 80% thinking, 20% typing, and 20% discovering you should have spent more time thinking. –  molbdnilo Mar 21 '12 at 23:15
Yep, the thinking part is obliviously necessary but it seems unreal to prove correct a program of million of lines of code. Yet, I agree that this way of programming can get handy in the future. –  Jefffrey Mar 22 '12 at 0:36
add comment

Formally proving the correctness of the program you're using is well-known to be extremely arduous and only suitable for the smallest programs. The amount of time necessary to formally prove anything but the most trivial programs correct is insane and not practical at all.

However, having a design and specification are essential tools, even if you don't prove your programs correct against them.

share|improve this answer
If that's all that they're doing, then I'll have to agree with you; well written code proves itself in itself. Still, proving a more abstract concept could benefit with this method, or at least a similar one. I guess the OP would need to provide an example. –  Jeffrey Sweeney Mar 21 '12 at 14:38
add comment

This isn't strictly known as Design By Contract, DBC is a marketing term used by Bertrand Meyers' company and the concept of using pre-conditions, post-conditions and invariants to develop a program was being used by Dijkstra while he was using structured programming.

For larger programs or for more challenging algorithms it is highly useful to be aware of the pre-conditions, post conditions and invariants. They can guide in writing the program and they help make your thinking much clearer.

share|improve this answer
add comment

The given/when/then scenario of unit testing contains the pre-conditions, post-conditions, and invariants of your program. If you are writing your tests correctly you are already documenting this. and simply need to put the test code in to words in your comments to appease the professor.

share|improve this answer
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.