i guess one could count the ability to create test cases without extending TestCase could count as a positive thing
On Wed, Oct 27, 2010 at 8:55 AM, Mark Volkmann <[email protected]>wrote: > That reminds me of JUnit 4. Supposedly the @Test annotation is a good > thing. I don't see how the ability to create test methods whose names > do not begin with "test" is a good thing. > > On Tue, Oct 26, 2010 at 6:36 PM, Augusto Sellhorn > <[email protected]> wrote: > > Annotations are a funny thing, you can (like anything) also abuse > > them. There's a project out there (don't know if I should point it > > out) that decided to create listeners via annotations instead of > > listener interfaces. > > > > It actually ends up with the code being less clear than the > > alternative. > > > > ex: > > > > public class TrumpetTest implements TrumpetListener{ > > public void playTrumpet(Event ev) { > > } > > > > public Test() { > > Trumpet trumpet = new Trumpet (); > > trumpet .addTrumpetListener(this); > > } > > } > > > > vs > > > > @Listener > > public class TrumpetTest { > > @PlayTrumpet > > public void annotatedListen(Event ev) { > > } > > > > public Test() { > > Trumpet trumpet = new Trumpet (); > > trumpet .addListener(this); > > } > > } > > > > Now the annotation approach makes it so that there are less > > addXXXListener() methods, and I can have an uber listener that has a > > list of annotations (@PlayTrumpet, @FixTrumpet, etc) but this makes > > the code harder to maintain. > > > > The annotation makes it so there's only one method signature for the > > events, with a shared event object and also (at least in the API I'm > > talking about) you can tag a method with an annotation with different > > args, you just don't get the event (or even know about the contract > > for the event). > > > > Horrible! > > > > On Oct 25, 6:41 pm, Liam Knox <[email protected]> wrote: > >> Yes fantastic metric characters are in measuring bolierplate > >> > >> i.e > >> > >> foo() { > >> t.s(); > >> > >> t.c(); > >> > >> } > >> > >> or > >> > >> @Transactional > >> foo(){} > >> > >> On Mon, Oct 25, 2010 at 10:31 PM, Kevin Wright < > [email protected]>wrote: > >> > >> > >> > >> > >> > >> > >> > >> > No, because that's based on an assumption that more lines = more > >> > functionality > >> > >> > Though I can see how those in favour of not removing boilerplate, and > >> > questioning the benefits of a 30% reduction might see this as a good > metric > >> > >> > On 25 October 2010 14:28, Liam Knox <[email protected]> wrote: > >> > >> >> Should we go back to measuring productivity by lines of code written? > >> > >> >> On Mon, Oct 25, 2010 at 10:26 PM, Augusto Sellhorn < > >> >> [email protected]> wrote: > >> > >> >>> This is really bizarre, I've heard people say that fewer lines of > code > >> >>> is desirable, but this is the first time I hear somebody say that X% > >> >>> fewer characters lead almost exactly to X% reduction in complexity! > >> > >> >>> --------------- > >> > >> >>> for(int > >> >>> indexOfAuthorInCurrentIteration=0; > >> >>> indexOfAuthorInCurrentIteration<=authorsFromNameQuery.length; > >> >>> ++indexOfAuthorInCurrentIteration) { > >> >>> Author currentAuthorBeingIteratedOver > >> >>> = authorsFromNameQuery[indexOfAuthorInCurrentIteration] > >> >>> // do something with the author > >> >>> } > >> > >> >>> --------------- > >> > >> >>> Nobody is saying you have to use super long names here, what you are > >> >>> saying is that less characters more % reduction in complexity, which > >> >>> leads to this > >> > >> >>> for (int i=0; i <= aq.length; ++i) { > >> >>> Author aa = aq[i]; > >> >>> // do something with the author > >> >>> } > >> > >> >>> Which I don't think results in any % less chances of bugs, as a > matter > >> >>> of fact it ends up being less readable than some reasonable and > clear > >> >>> names that could have been applied. > >> > >> >>> I hope in your code reviews you are not doing character counts and > >> >>> blasting developers on these bogus measurements. > >> > >> >>> -- > >> >>> You received this message because you are subscribed to the Google > Groups > >> >>> "The Java Posse" group. > >> >>> To post to this group, send email to [email protected]. > >> >>> To unsubscribe from this group, send email to > >> >>> [email protected]<javaposse%[email protected]> > <javaposse%2bunsubscr...@googlegroups .com> > >> >>> . > >> >>> For more options, visit this group at > >> >>>http://groups.google.com/group/javaposse?hl=en. > >> > >> >> -- > >> >> You received this message because you are subscribed to the Google > Groups > >> >> "The Java Posse" group. > >> >> To post to this group, send email to [email protected]. > >> >> To unsubscribe from this group, send email to > >> >> [email protected]<javaposse%[email protected]> > <javaposse%2bunsubscr...@googlegroups .com> > >> >> . > >> >> For more options, visit this group at > >> >>http://groups.google.com/group/javaposse?hl=en. > >> > >> > -- > >> > Kevin Wright > >> > >> > mail / gtalk / msn : [email protected] > >> > pulse / skype: kev.lee.wright > >> > twitter: @thecoda > >> > >> > -- > >> > You received this message because you are subscribed to the Google > Groups > >> > "The Java Posse" group. > >> > To post to this group, send email to [email protected]. > >> > To unsubscribe from this group, send email to > >> > [email protected]<javaposse%[email protected]> > <javaposse%2bunsubscr...@googlegroups .com> > >> > . > >> > For more options, visit this group at > >> >http://groups.google.com/group/javaposse?hl=en. > > > > -- > > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > [email protected]<javaposse%[email protected]> > . > > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > > > > > > > -- > R. Mark Volkmann > Object Computing, Inc. > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- http://mapsdev.blogspot.com/ Marcelo Takeshi Fukushima -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
