Heh, at one place I wrote some java code that would use reflections to test the getter/setters in a POJO so that it wouldn't end up with 0% code coverage.
Those sux when maintaining, investigating and debugging code. They break IDE functionality too. You can't put breakpoints in them. You don't see them properly in views.
It is trading off useless aesthetics over practicality.
IDE auto generation is frozen in time. You have a bunch of useless boilerplate you still need to look at to make sure nobody did something unexpected in them
When annotation generated or reflection based, you only have the really interesting ones in source code to care about
Comments
Heh, at one place I wrote some java code that would use reflections to test the getter/setters in a POJO so that it wouldn't end up with 0% code coverage.
getter setters w/o buisness logic seem like an antipattern though. let spring or some other annotation handle those
Those sux when maintaining, investigating and debugging code. They break IDE functionality too. You can't put breakpoints in them. You don't see them properly in views.
It is trading off useless aesthetics over practicality.
Eh, whats the difference between spring auto-generating them at build time via an annotation or an IDE auto-generating them at write time?
IDE auto generation is frozen in time. You have a bunch of useless boilerplate you still need to look at to make sure nobody did something unexpected in them
When annotation generated or reflection based, you only have the really interesting ones in source code to care about
coverage is not affected