I’m here at home in bed, off sick today, so I’ll say first up that anything stupid I say is because I am delirious
Anyway, I just read your post on this, and Chris’s, and thought I’d put in my 2c worth

And of course, I can only speak for myself, not Meyer

But anyway, first up, I think there’s some confusion about the whole thing of checking or not checking contracts. You say that programmatically checking them “boggles” you, and yet, in your preferred way of working, you say in point 1, that you “Define the pre and post-conditions in a block at the start of the module “.

Well, I think they can be 1 and the same thing !
And I think (again, just my take on what Meyer is getting at, I could be completely wrong) that this is exactly the kind of thing that Meyer was getting at - what you say agrees with what he was saying.

ie, the contracts are defined “separately” from the actual code of the module. However, they are still programmatic, and are not intertwined into the main part of the code, with if conditions etc. They are totally separated from the main code, so that the main code remains very clear as to what is happening. The main code does not cater for any broken contracts - it assumes the contracts hold.

Remember, Meyer was defining a whole new language, and environment - he wasn’t specifically talking about how to do things in Java, or .Net etc. In the end, he was really talking about a new system that he was devising, called Eiffel. We can emulate some of the ideas in some other languages, but as yet, it doesn’t all come across as he envisioned it in OOSC, for Eiffel.

So, where you have points 1 and 3 - defining the contracts separately, and then do not check them - well, in his Eiffel system, defining them is (or can be) pretty much the same as checking them. All you have to do is set a switch to check or not to check - you keep your main code unpolluted with defensive checking.

His system allows you to view the code, with the contracts hidden - so all you see is the main code. Or, alternatively, you can view only the contracts, and not the code.

In short, don’t get caught up in the whole thing about to check or not to check. What you have said you want to do, is what DbC lets you do. To check or not to check is largely irrelevant, and whether you do or not, makes no difference to what your code actually looks like (in Meyer’s Eiffel system !!! Remember, if other systems have poorly implemented DbC, then this is not what Meyer was talking about !!! Java still doesn’t have any good, supported, DbC - I have recently been looking. There’s a number of attempts, and they all seem to die out…)

So, write your contracts in a separate block, and if you want to check them, then flick the switch, without changing your “real” code. If your system doesn’t allow you to do this, then recognize that this is not Meyer’s vision of how things should be, and is not his fault

Ok….but that’s a very minor point in comparison to the real debate, as far as I’m concerned.
My position, much to Chris’s horror, is that in fact they ARE complementary
And I think that those who write off DbC in favor of TDD don’t realise the full potential of DbC, and how it can interact with testing.
(Or perhaps they write tests which are in fact contracts !)

The big difference between tests and contracts is that tests are specific, and contracts are general.
The first big problem with saying one is “better” than the other, is….PEOPLE.
People are different, and for whatever reason, some prefer one way, others prefer another. So, you simply can’t necessarily please everyone, with any one approach.

Here’s what to me is a very clear demonstration of the difference between them - in terms of my own personal experience.
Sometimes, when I’m reading a manual, I’ll be reading, reading…thinking, “ok ok, just show me an example so I can see what it really looks like !!!”
I want to see a specific example, or in our situation, a test ! A specific situation of how the rules are applied. So, in this kind of situation, I like specific examples, or tests.

There is another well known case, where specific examples are presented, and which shows that it can actually be hard to know what is really going on when presented with specific examples.
Such cases like :-

What is the next number in the sequence 3, 7, 13, 21, 31… ?

Here we have some specific examples, but, it still requires some thinking to know what’s “really going on”.
After a little while, you’ll realize that the sequence can be defined by the formula, n^2 + n + 1, and you think, I actually UNDERSTAND it now.
Specifics are great, but a formula, (or contract !) can actually lead to true understanding.

So, both specifics (tests) and general formulae (contracts) are both more useful at different times.

Of course, you can write generalized tests - which take in parameters, and use some “contract” to work out whether the result is correct…but I would argue, that in doing this, you are actually writing contracts, and are in fact doing DbC, even though you may think you’re doing TDD or some unit testing.
The mechanism may be slightly different to using annotations etc to write contracts…but it’s still DbC in my book !

Chris argues that TDD offers advantages at all level, whereas DbC doesn’t …I’m not sure I see this at all. If you can write a test for any level, then I don’t see why you can’t think about a contract for that level as well.

Ok, but what I see as the real advantage of DbC that you guys are ignoring, is that DbC solves the “oracle” problem for you, ie how to come up with the correct results for tests. How do you write your tests ? You …somehow…come up with the “answers”, the correct results that are to be expected. How do you do that ? Mostly…by hand, right ?
This means that writing unit tests is hard work ! You want 100 tests ? then you have to work out 100 answers… And so, …you end up NOT writing 100 tests. EVen something as simple as say, an addition routine, you might try a few inputs like, zero, or some negative numbers, or some big ones… and then you stop.
You’re confident that it works (and probably rightly so, given that it’s so simple ! and so you stop. However, even in something so simple, being human, we can miss things. Maybe we don’t realise what happens in Java when you add 2 really big numbers…and so don’t even think to check for it…

But, here’s the beauty of DbC. IF you turn the contracts on (don’t get upset, this is pre-release ok ! ….then EVERY run of the program, is in fact a TEST.
What this means, is that if you can generate massive amounts of test data, you can run this through the program…and just see what happens. If you get a postcondition violation (or a precondition violation not directly caused by the test data) then you know there is a bug. You can set up a system to generate test data, and run your program, and have it running continuously - checking zillions of combinations of input data, checking all paths through your code….all at no cost to you, except for the thought you put in to come up with contracts, which I would argue, is time well spent, regardless of whether you end up implementing them programmatically or not.

So, in summary, I would just say :-

- thinking up general contracts can give you a deeper, truer understanding of your system, than just handling specific instances
- actually implementing them can allow for massively automating your tests
- hence… DbC and TDD (or unit testing in general) are complementary. If it’s too hard to think up a useful, checkable contract, write some tests. If tests don’t give you true understanding, write some contracts. If you really want to expand your test coverage, then write some contracts.

Good read. I’ll be checking your exif data a little closer from now on. :p

I’m sure you know but in addition to the above you can also set P(rogram) mode to different program lines within the custom settings. ie. hi-speed proity, dof priority or MTF priority.

MTF Priority is an interesting one as it interrogates the lens for information on the best MTF data and favours those apertures. Handy feature if you’re looking for max performance from a given lens.