Sonar is destroying my job and it's driving me to despair • Hacker News Board

Re: Sonar is destroying my job and it's driving me to despair

#71

Post by hsbbxbyb » Thu, Jul 04, 2024, 5:57 AM UTC

lesuorac wrote: post #62

cuteboy19 wrote: post #42

Earlier quoted context omitted.

getter setters w/o buisness logic seem like an antipattern though. let spring or some other annotation handle those

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

Re: Sonar is destroying my job and it's driving me to despair

#72

Post by gewenyu99 » Fri, Jul 05, 2024, 4:20 PM UTC

Well, we built Trunk Check to address some of these issues. Maybe it'll suit your org better.

- We support hold-the-line: we only lint on diffs so you can refactor as you go. Gradual adoption. - Use existing configs: use standard OSS tools you know. Trunk Check runs them with standardized rules and output format. - Better config management: define config within each repo and still let you do shared configs across the org by defining your own plugin repos. - Better ignores: You can define line and project level ignores in the repo - Still have nightly reporting: We do let you run nightly on all changes and report them to track code base health and catch high-risk vulnerabilities and issues. There's a web app to view everything.

Try it and let me know how it goes. https://docs.trunk.io/check/usage

Re: Sonar is destroying my job and it's driving me to despair

#73

Post by watwut » Sun, Jul 07, 2024, 11:21 AM UTC

cuteboy19 wrote: post #42

lesuorac wrote: post #26

Earlier quoted context omitted.

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.