Zach D. wrote:
Such action causes avoidable and pointless work.
And to disprove this argument I will defer to the avoidable and
pointless work you will be causing those who maintain the software,
This is a completely illogical, and inherently contradictory, statement.
The issue is that a tool is supposed to be reliable. Reliability
includes the notion of preserving prior behaviour. This ensures that
people who invest their time in using the tool do not have their trust
in it destroyed by avoidable changes.
Further, by its very nature, a tool is used by vastly more people than
those that create the tool, otherwise it has little value. The idea
that a large number of people should be inconvenienced in order that a
few people are not strikes me as rather selfish and frankly,
unprofessional. Have you ever dared to make that type of argument to
your employer or client?
Yes, software evolves; and yes, there are many things we do in ignorance
that experience reveals as both unfortunate and wasteful. But, time is
money and causing test suites to fail by removing parts of the API just
because they appear ugly seems to me to break the contract that one
makes with those who choose to use your tool instead of another.
Let use consider this construct:
object.should be_close(value,delta)
why not
object.should be_close_to(value,delta)
Or
object.should be_near(value,delta)
Or
object.should approximate(value,delta) instead?
Which is “better” then the others? Which is “uglier”? Who cares? Pick
one and stick with it; or, if one feels compelled to improve the style
then at least keep that which already works, and is in use, working.