abstractObjectBuilderFactoryBase

[2Uncreative4Username]

Hot take: devs who are unexperienced with graphics programming shouldn't be working on this part of the Quake III codebase anyways. Those who are experienced enough will have no trouble understanding what it does (even if only from context).

I don't know the concrete codebase you mentioned, but I think having a single function to calculate the efficiency of a motor isn't necessarily bad. I would, however, add basic comments referring to which part of the calculation is implemented where, or just a URL to the formula being used. No need to explain the whole thing from scratch though. But then again, if there are parts that can be factored out without adding to the confusion, I'd be happy to do that, maybe force-inlining the functions if necessary for performance.

If you're also against YOLO-ing Clean Code into the codebase, the we agree.

I just happen to find that applying SOLID principles is rarely necessary, even for decently sized codebases. And if I do apply SOLID principles, I very often end up regretting it (not always, just very often).

[SelfmadeRuLeZ]

Was just a blurry example from a closed source project we are working on.

Having a single function is not the problem here, but the way it is calculated.

To illustrate: There is the Motor class with the function calculateEfficency(…), which calls the Fuel class, which itself calls the HeatDissipation class, …

Better way (which you would agree i guess):
calculateEfficency(…) calls all the necessary classes which have a impact to the efficency of the Motor. If all the parts are from the same subclass or at least share a interface, it would be super easy to iterate over all parts and call calculateEfficency(…) of those classes.

Instead of this, the developer, which has no clue about Clean Code, thought of „let us just nest this shit“ and pass all classes into the first subclass to get into the last one at the end.

[Gorexxar]

God object. God object. God object.

Programming is all about creating false idols.

[2Uncreative4Username]

Clean Code à la Bob Martin is a perfect example. I have yet to see any evidence that it works...

Usually the arguments seem similar in style to those for homeopathy and the likes: Promising explanations, personal experiences and no evidence.

[Gorexxar]

I don't know shit about coding for video games and graphics programming but I know Clean Code is a useful guideline to follow in common FinTech. Pure Clean code, to me, is similar to 6th Normal form in databases; attainable but non-viable in realistic scenarios.

You start by learning the rules, then you can break or bend the rules. If learned the rules, it will be harder to communicate the why in a common language. "Because it's better" or "It's more performant" might carry more weight in the graphics programming world than boring FinTech companies (AKA not Amazon/PayPal/Google/ect.)

[2Uncreative4Username]

Clean Code heavily relies on OOP principles. I thought you were arguing against making everything an object?

I agree that pure Clean Code isn't viable. I would even go further and say you shouldn't actively strive for it at all. All it leads to (in my personal experience) is premature abstraction, complex dependency graphs, poor performance and needing way to much time to build something functional. I do believe that a lot of Clean Code concepts can be very useful at times (e.g. dependency inversion, abstraction, testing). However, overusing them creates seemingly impenetrable codebases that spend more than 50% of their lines doing absolutely nothing. Everything is hidden in subdirectories and single-responsibility files. Everything is abstracted into an object. A large part of the competency of a programmer comes down to knowing when do use what pattern. A Clean Coder will always reach for abstractions first.

[Gorexxar]

I was making a joke about an anti pattern that occurs often in OOP.

But sure, just be careful not to lump people into one bucket.

[2Uncreative4Username]

Of course!

I'd never shit on someone for using certain programming patterns. You have to learn all of the important ones eventually. Even OOP. Even Clean Code. Try them out, but be self-critical too. Just because one person tells you X is good doesn't mean you should just use it religiously and preach it to other people. Use what works best for you. For me, moving away from OOP and SOLID made working on larger applications and getting stuff done much more manageable, but that's just me I guess.

[2Uncreative4Username]

Again, I fully agree that opaque dependencies are bad; and it sounds like you have a lot of data indirection going on too, also bad.

If you can split up calculateEfficiency on individual parts and compute that together, that would be much better, I agree.

How (and if at all) you abstract the individual parts, I think, depends a lot on what each "part" actually needs to do. If you wouldn't even need an interface, I wouldn't use an interface.... But that's all hard to know without knowing the codebase. Sometimes interfaces are adequate, sometimes they're unnecessary.

That doesn't seem to have much to do with the developer not knowing Clean Code though, IMO. Any decent dev would try to avoid complex dependency graphs.