Hacker News Reader

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.

View on HN

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

Reply on news.ycombinator.com