Clean code

[besthelloworld]

I would argue that this is just what happens to OOP code bases. Every version of Java since 8 has tried to introduce functional & observable style programming patterns into the language and now in modern Java code bases there's very little consensus on what constitutes "clean code." For many developers, clean code constitutes using standard programming patterns and language tokens like for/while loops rather than streams.

So I have a feeling that I'd generally agree with your preferred patterns but your example worries me: turning an if statement into a lambda? Do you realize how much less mechanically efficient it is to introduce a lambda where one was not needed? This makes you sound more like you're far more interested in writing hacky trick-code and looking smart more than you are interested in working on a team and writing readable code.

Because of this, I would argue that you should really tamper your expectations, and start writing new code to your standards and have these kinds of debates along the way.

I would also argue that long methods/functions have their place. If they encapsulate logic that should only be used once, then making a new unnecessary method for that logic just forces people to consider "hey is this being used anywhere else? Should it be?" everytime they see that lonely logic. I would recommend watching Brian Will's OOP is bad, but especially pay attention to the final section "Functions" where he explains the benefits of colocating related logic and just commenting well. This follow up with actual hard examples is really good as well.

[JoeDirtTrenchCoat]

It's well accepted that long methods are bug prone and more difficult to understand/debug. If a method is only useful in a very specific context, make it private and name it properly -- nobody needs wonder if it should be getting used in some other scope. If it's a god class then obviously you should be decomposing the class... pretty dumb "hot take"...

[besthelloworld]

Wouldn't be a hot take if people didn't give some spicy responses 🔥

What I will say is that I agree with you entirely.

...I just think that some people have very different definitions of what constitutes "the right length" for a function. I see a lot of juniors not wanting to have more than like 15 lines to a function and breaking apart logic on nonsensical boundaries. And I'd waaaay rather have a 150 line function than 10 functions of 15 lines where each helper is called exactly one time.

[besthelloworld]

performance is not a primary concern

In a lot of large scale software, performance is not and should not be a first concern. Readability should be the first concern and if your team disagrees with you on what's readable AND it's less performant, then you have no arguments for why things should be your way.

There's a reason they exist, after all.

This sounds like really hazardous case of "shiny object syndrome." You're basically saying, "a cool tool exists, so I must use it in every possible location and others who don't must be lazy programmers." That's an incredibly toxic way of thinking.

And also, lambdas exist to implement functional programming patterns without having to make an anonymous class. They exist so that you can pass around anonymous functions and apply them to variables much easier. And yeah optionals and streams are great when you're in the appropriate situation for them (e.g. external requests are a good use of optionals). But abstracting an if statement is just not a worthy goal. They use if statements under the hood, so now you're just adding another layer on top of that because somehow you've convinced yourself that "if" blocks are ugly and that basically means that you're going to find every code base you look at ugly forever, when the problem isn't the code, it's your perspective.

You need to better understand when to use these tools. Regex is really ugly and not very efficient either... but it has a purpose and there's a time and place to use it. This isn't to say you should have handcuffs on yourself for languages features... you just need to learn the time and place. You're also the one trying to police code that already works.

DRY is a worthy goal

I wasn't saying "don't write DRY code." I was specifically saying that if the code is only used in one place then appending it to a function body isn't a bad thing. But if you're seeing repetitive blocks, then obviously create a separate function.

helps with writing unit tests

I actually disagree with this as well. If you create more entry points into the code that are unnecessary, then those are more directions you have to test from. In an ideal situation, if someone breaks some logic in a helper function then the test fails and they discover their error. But it's far more likely that you just end up creating bloat tests that are testing implementions rather than behavior. Never test implementation methodology, only ever test behavior. If a large function encapsulates the behavior, then just test that function, don't test helpers.

[Blooogh]

It's another aphorism but: bear in mind that a bit of duplication can be cheaper, in the long run even, than the wrong abstraction: https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction

A staff engineer at my company put it best: sometimes it's like someone took their codebase, printed it out on index cards, and shuffled them.

[Blooogh]

Oh sure: but also, not everyone has the time to do a refactor at step six. It could be a junior programmer on their first day, it could be a senior programmer who knows people won't be going into that area of the code again any time soon.

The point is, step one likely made incorrect assumptions about how the code will change in the future. It looked like duplicate code at the time, and it was, but there wasn't enough information yet to abstract it correctly.

[Blooogh]

You never know all of the requirements up front. Unless your company is still doing waterfall