Yes, you need to push back on those people. They're the type that get high on code golf and end up writing unmaintainable one-liners measured in kilobytes for fun.

I review a ton of code and have a bunch reviewed in turn. I don't remember that last time I've had this come up. Either direction really. I guess I'm lucky. We just split naturally in similar places.

I guess this is go, and I don't know what the scoping is. In C++ I also suggest putting as much in the if as possible, because it limits the scope of the variables.

Well it actually depends.

Does it make the code more readable? Like you have several if statements using the same things (and/or else if)? Yeah then it's probably good.

If you have an if (work.lengt() == 0 && stacked_work.length() == 0) and that's it, probably not. Depending of whats happining then of course.

Be creative guys! But also dont be too creative :-) Think about the poor coder doing something with all that in a year or two, let's make his life less miserable (It's probably you, too).

I think it's a bad analogy because it'll distract some people.

I don't think a lot of people think that mushrooms are vegetables in any sense. If you check culinary lists of vegetables, they don't contain edible fungi.

Ah I hate that, too. It speaks of bad abstraction, over eager abstraction or unnecessary coupling that is the hidden behind this. Difficult to fix though without essentially starting over.

I absolutely agree that method extraction can be abused. One should not forget that locality is important. Functionnal idioms do help to minimise the layer of intermediate functions. Lamda/closure helps too by having the function much closer to its use site. And local variables can sometime be a better choice than having a function that return just an expression.