To all self made seniors (and those who got granted this title because it was a morale boost): is it really so difficult to grasp ideas like: Single responsibility? Don't repeat yourself? Encapsulation?

Seriously? Is it difficulty level of some quantum physics or what?

I'm not a fucking genius myself either, but when I see 300-500 LoCs function, accepting 10 parameters, having half of code duplicated in different parts of solution - I really wanna start firing people ON THE SPOT.

P.s.
To all shitty developers advocates - I know that everyone makes mistakes sometimes - I'm talking here about consistent "don't give a shit about code" behaviour.

I always wonder if I’m missing some cool technique for having “too many” parameters to a function. I have a simulation lib and there’s a main “do_run” type of entry point which takes about a dozen parameters. Sure, some are optional...but still...a dozen.

I see people create a record or classes to handle them, and then pass the “config” structure in...but that’s basically the same thing. Worse, in fact.

I can break it up into a number of sub functions...but then the client of the function is responsible for calling them all.

So, is there a better way of defining a function that needs 12 separate pieces of data?

@platypus object, config object, builder pattern, fluent syntax (depending of your concrete need).

It's not a problem that someone does not know something. It's only a problem if that someone does not want to know. Lot's of so-called seniors (and juniors) with this attitude.

@bzq84 Moving parameters to an object (or tuple, record, etc) doesn’t seem like a particular improvement to me...unless I’m using that config structure in multiple places. It’s an additional level of indirection and obfuscation.

Fluent syntax is an interesting idea, though. I need to ponder that.

@platypus no. It's adding semantic meaning and proper structure to your data.

@platypus working full time on simulation code myself, I know exactly what you are talking about. And tbh I have to side with @bzq84, despite him being a bit of a smart-butts here: Using a struct or class is absolutely the better solution.

I have in recent years even started to make these monster-functions into class methods - even if that class is only used for this one function. The advantages are:

* A lot less argument writing

* You can easily emulate "named parameters" in languages that still don't fucking get that this is a good idea *cough* C++ *cough*

* Breaking the mega-function down into smaller units becomes MUCH easier when you don't have to always pass this huge argument list around.

* Especially when you have Input and Output arguments at the same time bundling them into dedicated objects not only improves the readability, but also makes it easier to create several instances of the output args e.g. when you do multi-threading or just successive calls.

@DirtEffect normally I'm pretty friendly guy 😉 always willing to help. I'm just frustrated recently due to coworkers etc.

When I can bundle some of the parameters into a structured object that has meaning in the domain then yes...absolutely. Worth doing.

But, I’m not use that an object with X properties is an improvement on X parameters. If I’m passing all that data around all the time then there’s some value in having it all in one variable, of course.

But I’m not convinced that 10 fields are an improvement over 10 parameters.

@platypus when you keep in object, then you're not moving data around, but pointer/reference to that data. And it is structured, meaning easier to understand, modify, and reason about. IT (information technology) is all about storing, handling, manipulating data. Thus - choosing proper structure of your data is basically half of success.

What is a "self made senior"?

@DirtEffect C++ does not have named parameters because it will bloat the language processor and will drastically increase complexity of calling code. You can use structs if you want to do that crazy stuff already.

@iiii Oh yeah we really have to take care not to bloat the C++ language processor... That would be terrible, wouldn't it :) No I mean seriously... How much more bloat can named parameters cause in a language that is actually 3 languages intertwined, that has 5 different ways to create an object instance and a gazillion ways to hand over arguments.

Yeah I know, and I do use structs for that purpose. Just feels a little last century to do that tbh.

@bzq84 Got it :)

@iiii "self made senior" is when someone put "senior" in CV because "why not".

@DirtEffect having named parameters is not different from having a shit ton of parameters and passing "null" in most, all on the call stack. So adding named parameters is actually a reinforcement of bad design which would harm performance.

If you want bling, then use languages that don't care about performance.

@bzq84 what's so "self made" about that?

@iiii true. I should call it "self assigned". Wrong wording in my original rant.

@iiii so how's that different from using a struct then?

@DirtEffect at least a reference to struct will take only one pointer to pass everything. If you're copying everything, then, sure, it's identically bloated.

@iiii valid point... Still, considering that C++ is trying to optimize the code during compilation anyway, I guess the performance difference would be small-ish, depending on the use case of course.

@DirtEffect I still stand behind the idea that named parameters, even if convenient, promote pretty inefficient software structure.

@iiii I think this is a point we can agree on.