On Apr 27, 2005, at 5:33 PM, James Britt wrote:

> Dave Fayram wrote:
>> Documentation can lie. Code cannot lie. Therefore, the code is
>> authorative. :)
>
> I generally find argument by non sequitur unpersuasive.
>
> Having code that compiles and runs does not mean you have the code you 
> want.

Yes, but this code does not lie about what it *does*.  (Though, in all 
fairness, it can deceive.)  I think Dave's point is that docs can lie 
about that, but the code just does what it does.

> You merely have the code you have.

I think what you are getting at is intention.  And "intentiion 
revealing code" is just another form of documentation, as subject to 
inaccuracy as anything in a comment.  Code cannot lie, but it *can* 
deceive.  I see deceptively misnamed methods all the time where I work.

> This is similar to arguments against unit tests: My code compiles, so 
> it can't have bugs, so it must be correct, so I do not need unit 
> tests.
>
> And I don't buy that either.
>
> BTW, what should one do when given code that does not pass unit tests? 
> Assume the main code is authoritative, and therefor correct, and 
> change the unit test?

You decide on the right course of action, then do that, without making 
a mistake.  ;-)

Your dilemma is precisely the reason for "test first."  This way, there 
is a compelling reason to say that the test is authoritative.  It is 
also the reason for "continuous integration" otherwise, you can be 
stuck in the situation above and not know which is broken.  But 
seriously, there is no absolute here either.

--Peter


--
There's neither heaven nor hell, save what we grant ourselves.
There's neither fairness nor justice, save what we grant each other.