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%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%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%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]. > 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]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
