Is this kind of Design by Contract useless?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.