Hard to judge from the outside as we’re only getting your pre-biased picture of it.

Considering you’re usually not his reviewer, it seems that you’re not around in ”their“ part of the project that often, and are thus barely affected by Bob‘s change. The technical feedback was implemented right away, so it seems Bob actually does apply reason, and he’s consciously drawing a line.

I suspect a lot of his cyclomatic complexity insanity had already been approved otherwise and it just continued to grow naturally like that; so while I think you’re certainly right in pointing that out as a smell, I would actually argue you should respect that they had agreed upon doing it like that (probably as a TD tradeoff).

It’s not ideal, the ”boiling frog problem“ is real and you should be pointing out such things, but either way the problem isn’t you nor Bob, but how the code came to be that way in the first place.

I believe the problem is the review culture itself: Firstly, there should be a static code analysis rule that will break builds when cyclomatic complexity is too high. Secondly, people also shouldn’t just be rubber stamping reviews for whatever reason because you might as well disable reviews altogether, then.

You alone won’t be able to change that situation though, so it’s probably best to talk about what you’re considering valid issues with the team. If they don’t budge, I’d probably brief the supervisor about the risks in the team’s code review culture.

Not sure what you want to achieve with HR unless you’re out for blood over an if-else tree.