Are you really using JUnit during your development?

[Elliotte Harold]

J. B. Rainsberger wrote:

> Indeed. If I violate your precondition, then I am writing defective
> code. There are a few remedies:

A nice list. However, I would claim only 1-3 are remedies.
Documentation, including tests as documentation, are not remedies. They
are useful, certainly, but they should not be relied on. Much brutal
experience proves that:

A. Programmers cannot be relied on to read documentation
B. Programmers cannot be relied on to run tests

> 1. Be nice and tolerate my indiscretion, say by substituting sensible
> default values and continuing.
 >

> 2. Telling me directly, "You shouldn't do that," by throwing a specific
> exception that explains my mistake.
>
> 3. Telling me indirectly, by failing is some deterministic, by
> non-obvious way.
>
> 4. Providing me examples of how not to violate your precondition.
>
> 5. Documenting the precondition and warning me that violating it leads
> to "undefined behavior".
>
> 6. Providing Contract Tests that I can inherit to help me know that my
> code won't violate your precondition.
>
> There are others, I'm sure.
>
> It looks as though you reject #5 out of hand, and I agree, but all the
> others are viable choices. I would choose the one providing the best ROI
> for the situation. In a language that checks preconditions for me, I
> would get #2 for free. In Java, which doesn't, it depends on the cost of
> violating the precondition. If it's anything like persistent data
> corruption all the way up to loss of life, I would probably insist on
> #2. If it's nothing worse than having to retry one of a batch of
> transactions, I might go with #1. Still, I would probably insist on #4
> and prefer #6.

--
Elliotte Rusty Harold  elharo@...
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/junit/

<*> To unsubscribe from this group, send an email to:
    junit-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 

[Elliotte Harold]

Michael Feathers wrote:

> Frankly, I wouldn't want to have only #5 at the API level, but I think
> that this tendency we have to believe that we can not have an agreement
> with users that is not enforced by code leads to a great deal of
> trouble. Particularly in the area of visibility.. many developers assume
> that no written agreement can be sufficient if something is made
> public.  I think that the issue is that we are not used to thinking
> about agreements beyond the code and we're not used to holding people to
> them.

I'd rephrase that a little. We have decades of experience with
documenting software and APIs and trying to make decrees (not agreements
as I'll explain in another post) about how it must be used. Experience
has proven that this doesn't work well. Consider the issues with even a
very well-known code base like Java with very well known and documented
design principles. How many mucked up hashCode()-equals()
implementations do we still encounter? Ten years ago, it was even worse.
  And don't get me started on runtime vs. checked exceptions. Even major
APIs pushed through the JCP still get this exactly backwards. You need
documentation, certainly, but documentation alone is not sufficient for
robust code.

By contrast, things that we can enforce in code do seem to work pretty
well. That we also have decades of experience telling us. Garbage
collection improves on manual memory management. Checked exceptions get
programmers to write a lot more error handling code than documentation
ever did. (Not quite as much as they should, of course, but a lot more
than they used to.) Automated unit tests (ideally run without programmer
involvement on a continuous integration server) keep programmers from
breaking the build. Having the source code repository either verify
formatting  or reformat code before checking it in keeps badly formatted
code from being checked into the source code repository.

These aren't absolutes. They are matters of degree. But they are large
matters of degree. We know these things. We've learned them through
experience. Rules we enforce in code and systems are far more likely to
be followed than rules we merely document.

--
Elliotte Rusty Harold  elharo@...
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/junit/

<*> To unsubscribe from this group, send an email to:
    junit-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 

[Elliotte Harold]

Michael Feathers wrote:

> Frankly, I wouldn't want to have only #5 at the API level, but I think
> that this tendency we have to believe that we can not have an agreement
> with users that is not enforced by code leads to a great deal of
> trouble. Particularly in the area of visibility.. many developers assume
> that no written agreement can be sufficient if something is made
> public.  I think that the issue is that we are not used to thinking
> about agreements beyond the code and we're not used to holding people to
> them.

An agreement might work. I've never seen anyone try one. Instead what
I've seen is the developers issue pronouncements from on high about how
users must use their software and APIs, and then be appalled when users
ignore them. Actually sitting down and invoking the users in the design,
and getting their explicit buy-in would be an interesting exercise. Hmm,
you know I have seen that and I have even done that, but only with a
small subset of the user base. For a project with a large user base, I
don't think you could ever expect meaningful discussion and agreement
with each individual user.

Now I'm not objecting to pronouncements, mind you. I'm a very
patriarchical designer in my own APIs, and I make lots of pronouncements
from on high. However I don't delude myself that the users have somehow
agreed to this. That's why I enforce the pronouncements in code.

--
Elliotte Rusty Harold  elharo@...
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/junit/

<*> To unsubscribe from this group, send an email to:
    junit-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 

[Elliotte Harold]

Michael Feathers wrote:

> There are some exceptions.  One is the Eclipse API Rules of Engagement:
> http://www.eclipse.org/articles/Article-API%20use/eclipse-api-usage-rules.html
>
> It's a contract above the code and it has some great ideas.  I really
> like the idea of "soft final" for instance.  It's like a license
> agreement.. you can do this (subclass and override, etc) and we won't
> prevent you, but if you break the rules we can't be responsible for you.


It's not a contract because I haven't agreed to it. I may not even have
read it or be aware of its existence. Software licenses have similar
issues. Software publishers are attempting, with some success, to get
legislators and the courts to rewrite contract law to support their
desires. However, leaving that aside if you care about the users and
usability, then you should not confuse mere documentation with a
negotiated agreement. The latter is much more effective, but that's not
what we have here.


--
Elliotte Rusty Harold  elharo@...
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/junit/

<*> To unsubscribe from this group, send an email to:
    junit-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 

[Michael Feathers]

belugabrain wrote:

>
>#1 doesn't help anybody, in the long-term.
>It doesn't inform the client that they messed up, but merely lulls
>them into a false sense of security that their code is fine.
>There's not often a sensible default to use - and if there was, it
>probably wouldn't be to the client's liking anyway.
>The best example I can think of for how meeting criteria #1 can
>backfire is the behaviour of Internet Explorer. Give it some HTML
>with a missing </td> tag and it will silently provide one for you.
>All this has done is to relieve thousands of web developers from the
>responsibility of ensuring that they produce correct markup.
>It really is a case of treating the symptoms whilst allowing the
>disease to spread in an unchecked manner.
>#5 covers a vast majority of cases - as Michael points our, we deal
>with 'terms and conditions' in so many other parts of our life, why
>not do so whlst carry out our chosen profession.
>
>Bob
>
>P.S. If we were to implement #1, surely it would be documented by #5?
>  
>

#1 is usually a bad choice, but there are narrow cases where it
applies.  There are some systems that have to run continuously, and
munging a bad request into an action is far better than doing nothing or
stopping.  I agree through, that is bad in general.

IE is an interesting case.  Microsoft could have taken a hard line, and
yes we probably would have been better off, but I'm guessing that the
reason they developed tolerance for bad input was purely competitive.

On #5, I mentioned earlier that my preference is to give users of an API
a better experience.  I do think it's interesting, though, that this
issue of whether an API should be permissive leads to discussions that
parallel contemporary politics: should rules be enforced strictly?  
Should people be accountable for their own actions?  If they aren't,
will it lead to bad behavior?

Lawrence Lessig wrote a while ago that code is law in a way, so I guess
it makes sense that these issues come up.


Michael Feathers
www.objectmentor.com


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/junit/

<*> To unsubscribe from this group, send an email to:
    junit-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 

[Michael Feathers]

Elliotte Harold wrote:

>J. B. Rainsberger wrote:
>
>  
>
>>Indeed. If I violate your precondition, then I am writing defective
>>code. There are a few remedies:
>>    
>>
>
>A nice list. However, I would claim only 1-3 are remedies.
>Documentation, including tests as documentation, are not remedies. They
>are useful, certainly, but they should not be relied on. Much brutal
>experience proves that:
>
>A. Programmers cannot be relied on to read documentation
>B. Programmers cannot be relied on to run tests
>  
>

So, (playing devil's advocate), we should treat them like babies?  How
will they act when we do?

Just playing devil's advocate here for the sake of discussion.. see my
point?

Michael Feathers
www.objectmentor.com



 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/junit/

<*> To unsubscribe from this group, send an email to:
    junit-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 

[Michael Feathers]

Elliotte Harold wrote:

>Michael Feathers wrote:
>
>  
>
>>Frankly, I wouldn't want to have only #5 at the API level, but I think
>>that this tendency we have to believe that we can not have an agreement
>>with users that is not enforced by code leads to a great deal of
>>trouble. Particularly in the area of visibility.. many developers assume
>>that no written agreement can be sufficient if something is made
>>public.  I think that the issue is that we are not used to thinking
>>about agreements beyond the code and we're not used to holding people to
>>them.
>>    
>>
>
>I'd rephrase that a little. We have decades of experience with
>documenting software and APIs and trying to make decrees (not agreements
>as I'll explain in another post) about how it must be used. Experience
>has proven that this doesn't work well. Consider the issues with even a
>very well-known code base like Java with very well known and documented
>design principles. How many mucked up hashCode()-equals()
>implementations do we still encounter? Ten years ago, it was even worse.
>  And don't get me started on runtime vs. checked exceptions. Even major
>APIs pushed through the JCP still get this exactly backwards. You need
>documentation, certainly, but documentation alone is not sufficient for
>robust code.
>  
>

I'd argue that by and large, Java has been very successful.  It provided
enough hand holding to allow average programmers to deliver a wide array
of good applications.

When they designed Java, they knew that they were targetting the middle
of the road... they left out a slew of features which would have made
life easier for more advanced developers and they did it deliberately to
make the language more approachable.  Despite that, there are people who
still screw up and they screw up precisely because the language offers
enough freedom to screw up.  On balance, that's okay because if it
didn't it would probably be far less functional than it is.

A lot of the backlash that we are seeing against Java right now comes
from the fact that many people are discovering that they can be more
productive without the hand holding, and they are willing to assume
responsibility to leave it behind.

>By contrast, things that we can enforce in code do seem to work pretty
>well. That we also have decades of experience telling us. Garbage
>collection improves on manual memory management. Checked exceptions get
>programmers to write a lot more error handling code than documentation
>ever did. (Not quite as much as they should, of course, but a lot more
>than they used to.) Automated unit tests (ideally run without programmer
>involvement on a continuous integration server) keep programmers from
>breaking the build. Having the source code repository either verify
>formatting  or reformat code before checking it in keeps badly formatted
>code from being checked into the source code repository.
>
>These aren't absolutes. They are matters of degree. But they are large
>matters of degree. We know these things. We've learned them through
>experience. Rules we enforce in code and systems are far more likely to
>be followed than rules we merely document.
>  
>

True, but it is a double edged sword.  It works when people don't need
the freedom to deal with exceptional cases, or when they do need the
freedom and have it.

Michael Feathers
www.objectmentor.com



 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/junit/

<*> To unsubscribe from this group, send an email to:
    junit-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 

[Michael Feathers]

Elliotte Harold wrote:

>Michael Feathers wrote:
>
>  
>
>>Frankly, I wouldn't want to have only #5 at the API level, but I think
>>that this tendency we have to believe that we can not have an agreement
>>with users that is not enforced by code leads to a great deal of
>>trouble. Particularly in the area of visibility.. many developers assume
>>that no written agreement can be sufficient if something is made
>>public.  I think that the issue is that we are not used to thinking
>>about agreements beyond the code and we're not used to holding people to
>>them.
>>    
>>
>
>An agreement might work. I've never seen anyone try one. Instead what
>I've seen is the developers issue pronouncements from on high about how
>users must use their software and APIs, and then be appalled when users
>ignore them. Actually sitting down and invoking the users in the design,
>and getting their explicit buy-in would be an interesting exercise. Hmm,
>you know I have seen that and I have even done that, but only with a
>small subset of the user base. For a project with a large user base, I
>don't think you could ever expect meaningful discussion and agreement
>with each individual user.
>  
>

Well, there's the Eclipse process and that seems to be working.  If a
new version of Eclipse comes out and your plugin breaks because you
ignored the rules of engagement, it's your responsibility, and that
happens.  The thing that Eclipse did do, however, is build a community
with enough large successes to keep the project viable despite the
smaller failures.

>Now I'm not objecting to pronouncements, mind you. I'm a very
>patriarchical designer in my own APIs, and I make lots of pronouncements
>from on high. However I don't delude myself that the users have somehow
>agreed to this. That's why I enforce the pronouncements in code.
>  
>
And it's that sort of patriarchical design that I feel is pretty much
inappropriate these days.  None of us are omniscient.  And, in fact,
many of of us didn't see that people might want to write tests for code
that uses our APIs eventually, for instance.

I'm sympathetic to patriarchical design because I know that it is fun.  
Design is all about constraints, and one of the cool things about
software is that in much of our work we don't have terribly tight
constraints on the form of our solutions.  If we did, the industry's
code might look better.  The cool thing about API design is that it is
an area which offers or seems to offer tight constraints: "you have to
get the API exactly right the first time or else!"  It's a rush when we
get that all right, but I think it's important to distinguish between
what a problem really requires and our desire to solve hard problems.

Michael Feathers
www.objectmentor.com


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/junit/

<*> To unsubscribe from this group, send an email to:
    junit-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 

[Jason Rogers-2]

J.B.¹s response is well stated.  I would like to add that simplicity is not
measured only in lines of code (that¹s like saying my productivity can
somehow be measured by KLOCs :)

I think the more telling measure of simplicity is in the maintain-ability
and test-ability of code.  This is where Interfaces show their true
strength.

-- Jason


On 9/5/06 8:54 PM, "J. B. Rainsberger" <jbrains@...> wrote:

>  
>  
>  
>
> Elliotte Harold wrote:
>
>> > Robert Martin wrote:
>>>>> >  >>> Elliotte, what are the downsides of interfaces, in your opinion?
>>>> >  >> 1. Excess complexity
>>> >  >
>>> >  > They make receiving a message more complex, it's true. They make
>>> >  > sending a message much simpler. Or rather, they add more lines of
>>> >  > code on the receiving side; but they eliminate dependencies on the
>>> >  > sending side. The benefit of those eliminated dependencies is very
>>> >  > powerful.
>> >
>> > I'm not sure I believe the second part. In practice, replacing a
>> > concrete-class based solution with an interface-based solution expands
>> > the complexity for the caller. What used to require a single class now
>> > typically requires three: a factory to create the factory, the factory
>> > itself, and the interface you're actually trying to create. I'm not sure
>> > you really need all that, but you need at least two pieces where you
>> > previously needed one, and in practice three is what we usually seem to
>> > end up with. (Think of DocumentBuilderFactory, DocumentBuilder, and
>> > Document in JAXP/DOM for example). And of course there are still
>> > concrete classes for each of these. We've turned what could have been
>> > one concrete class (Document) into six separate pieces! What could have
>> > been this:
>> >
>> > Document doc = new Document();
>> >
>> > is now this:
>> >
>> > DocumentBuilderFactory factory = DocumentBuilderFactory.getInstance();
>> > DocumentBuilder builder = factory.newDocumentBuilder();
>> > Document doc = builder.newDocument();
>
> Be careful! The Builder pattern is by no means needed to create an
> instance of an interface. JAXP/DOM combines, for whatever reason, the
> Singleton, Abstract Factory and Builder pattern, when all you really
> need is this:
>
> Document document = new WritableDocument();
>
> I could see using the Builder pattern to simplify the interface for
> constructing a document, separating creating a document from reading it,
> but by no means does JAXP/DOM do what it does because of /interfaces/.
>
> It's true that if you have a bunch of related interfaces (like in a GUI
> toolkit), you might want an Abstract Factory, but neither Singleton nor
> Builder enter the picture just because you have interfaces.
>
>> > I fail to see how that's simpler.
>
> It's not, and interfaces didn't make it more complex: the Singleton,
> Abstract Factory and Builder patterns did. If this is a representative
> example of why you find interfaces unnecessarily complex, then I really
> believe you're blaming the wrong part of the design.
>
> Take care.

[Non-text portions of this message have been removed]



 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/junit/

<*> To unsubscribe from this group, send an email to:
    junit-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 

[Elliotte Harold]

Michael Feathers wrote:

> So, (playing devil's advocate), we should treat them like babies?  How
> will they act when we do?

They will learn the right way of doing things, just as children do when
corrected. This does presume that the provider programmer knows more
about the problem domain than the client programmer, but if the provider
doesn't, then why are they publishing an API for others to use in the
first place?

None of us are experts in every domain we work in. We need to rely on
the wisdom of others who are experts in those domains, as encapsulated
in the libraries they've published, rather than asserting that we always
know what's best for everything and in every situation. Of course, we
can each be experts in some fields, and those are the fields in which we
publish libraries for the use of other, non-experts. (I have seen
libraries designed by non-experts, and they cause more harm than good.)

--
Elliotte Rusty Harold  elharo@...
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/junit/

<*> To unsubscribe from this group, send an email to:
    junit-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 

[Elliotte Harold]

Michael Feathers wrote:

> And it's that sort of patriarchical design that I feel is pretty much
> inappropriate these days.  None of us are omniscient.  And, in fact,
> many of of us didn't see that people might want to write tests for code
> that uses our APIs eventually, for instance.

Let's try to stay away from absolutes like omniscience and focus on
relative quantities instead. Just because none of us are omniscient
doesn't mean none of us know better, especially in particular domains.

While I would not presume to tell a statistician how to use a statistics
API, I wouldn't presume to design one either because I am not an expert
in the field. I do know just enough about statistics to be dangerous.
That is why when I need to write statistics code I go looking for a
statistics library that will help me by, among other things, revealing
the gaps and flaws in my understanding.

By contrast, when I'm working with XML, I probably do know better than
most what is needed, which is why I have written my own API. However
there probably aren't 100 people who know XML as well as I do, and an
API designed just for them wouldn't be very useful. Instead I publish a
library that is appropriate for people who do know less than I do within
the specific field of XML. Knowing less is perfectly fine. Lord knows
most developers have better things to do with their lives than studying
the arcana of the various XML specifications.

Do people occasionally get rubbed wrong by the strictness of my API?
Yes. However in almost every case, that's because what they want to do
is wrong and contrary to their needs. They just don't know know as much
about XML as I do so they don't realize that. The problems they have
using my API are symptoms of a deeper underlying problem with their
understanding and use of XML. Because my API refuses to let them do what
they want, they learn the right way of doing things.

There is one exception, by the way. I have exactly one user of XOM who
actually understands XML at a pretty deep level but who's still rubbed
wrong by the strictures it imposes. He went ahead and forked the project
to support his unique needs. That's the ultimate escape hatch, but once
he's forked it's now his project and not mine so I'm no longer
responsible for what he does with the library.

Think of it this way: it's like designing a car to run on the public
roads. It's not just the driver of the car you have to worry about. You
also have a responsibility to other drivers, pedestrians, insurance
companies, and indeed everyone who breathes on this planet. Their needs
sometimes outweigh the needs or desires of the driver. Now if the driver
opens up the hood and manually disables the emission control system and
various safety features, there's not much you can do about it, but
you're not responsible for it either. But if you ship a car that spews
noxious emissions and injures pedestrians as soon as the buyer drives it
off the lot, you are responsible for that. If the car only does this,
when driven 75 mph or faster, you're still responsible for that, even if
you pout a warning in the owner's manual and the fine print of the sales
contract saying, "Don't drive faster than 75 mph." It's much better to
design the car so that proper operation doesn't rely on unenforced limits.

--
Elliotte Rusty Harold  elharo@...
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/junit/

<*> To unsubscribe from this group, send an email to:
    junit-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 

[J. B. Rainsberger]

Michael Feathers wrote:

> I'll answer this assuming that you're talking about API code, not
> application code. If that's not the case, let me know.

I think I'm talking about API code, because that's the context Elliotte
is mostly coming from.

> In some systems #1 is the best answer, but those situations are rare
> and, as a strategy, it can lead to misunderstandings.. #2 and #4 are
> great strategies and I like #6 as well.
>
> I think it's interesting to talk about #5, though. In nearly every
> other area of life, we deal with warranties and license agreements in
> which we explicitly assume responsibility for our use of products and
> services. In software we often try to protect clients from themselves
> and don't consider notice a fair grant of responsibility.
>
> The fact is, it isn't universally true. Lots of luck having Win32 save
> you from violations of its preconditions, for instance. :-)

Yes, but Win32's design is broken for other reasons. :)

> Frankly, I wouldn't want to have only #5 at the API level, but I think
> that this tendency we have to believe that we can not have an agreement
> with users that is not enforced by code leads to a great deal of
> trouble. Particularly in the area of visibility.. many developers assume
> that no written agreement can be sufficient if something is made
> public. I think that the issue is that we are not used to thinking
> about agreements beyond the code and we're not used to holding people to
> them.
>
> There are some exceptions. One is the Eclipse API Rules of Engagement:
> http://www.eclipse.org/articles/Article-API%20use/eclipse-api-usage-rules.html 
> <http://www.eclipse.org/articles/Article-API%20use/eclipse-api-usage-rules.html>
>
> It's a contract above the code and it has some great ideas. I really
> like the idea of "soft final" for instance. It's like a license
> agreement.. you can do this (subclass and override, etc) and we won't
> prevent you, but if you break the rules we can't be responsible for you.

I have found in the past several years that relying on code to solve a
people problem is dubious at best. It might be that I now underestimate
its effectiveness, but it seems to work better for me than
overestimating its effectiveness, as I used to do.
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/junit/

<*> To unsubscribe from this group, send an email to:
    junit-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 

[J. B. Rainsberger]

Elliotte Harold wrote:
> Checked exceptions get
> programmers to write a lot more error handling code than documentation
> ever did. (Not quite as much as they should, of course, but a lot more
> than they used to.)

...a lot more, by percentage? I doubt it. For every person that handles
checked exceptions, there are, I'm guessing, several (dozens?) that
either simply wrap them in unchecked ones (fine with me) or do catch {}
(oy). This pattern repeats, over and over.

The programmers that /do/ write error handling code are the ones that
would have done it before, if it had required less of an investment.
Those are the same programmers who will write equals() and hashCode()
correctly if they know that EqualsTester exists and how to use it. They
don't need code enforcement; they can get by with useful tools.

Take care.
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/junit/

<*> To unsubscribe from this group, send an email to:
    junit-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 

[J. B. Rainsberger]

Elliotte Harold wrote:

>
>
> J. B. Rainsberger wrote:
>
>  > Indeed. If I violate your precondition, then I am writing defective
>  > code. There are a few remedies:
>
> A nice list. However, I would claim only 1-3 are remedies.
> Documentation, including tests as documentation, are not remedies. They
> are useful, certainly, but they should not be relied on. Much brutal
> experience proves that:
>
> A. Programmers cannot be relied on to read documentation
> B. Programmers cannot be relied on to run tests

You asked Michael earlier to stay away from absolutes. I'm asking you to
do the same. There are some programmers who /will/ run the tests and
some who won't. What can you say about each group? How likely is each
group to do something useful in /any/ situation?

I think if we give them good tests, they will run them. I don't think
enough of us have done that to be sure they won't.
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/junit/

<*> To unsubscribe from this group, send an email to:
    junit-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/