Actually in my own code I also have some functions with a lot of parameters, and some constructors for database-entities also have a lot of parameters.
In the case of functions with a lot of parameters, mostly these are builder-type functions to build test data instances where most values are defaulted and a typical invocation will specify only 2 or 3 non-default values.
And the OP’s case about Enum constructors with a lot of arguments, I do recognise that situation and data classes are probably not going to help.
I agree that readability is more important than brevity. Therefore I would prefer the named argument syntax myself in my own code for such situations, for readability, because the more parameters a function has, the harder it becomes to quickly see what each parameter is. Especially when various parameters are skipped to apply defaults.
When I see a call like:
foo(_, _, true, _, 42, _, _, _, _, "Bar")
Really - what would ‘true’, ‘42’, or ‘Bar’ really mean to that function? I’d prefer to see:
foo(isWorkflowTerminatingStatus = true,
pricingSurchargeForResolution = 42,
requiredUserRoleForAction = "Bar")
Then at least I’d know what I’m talking about when I pass in 42!
Well I guess it’s a matter of preference but I’ve seen enough code over the years to know what I find easier to understand!