While making a struct creates some overhead at run-time, packaging a bunch of frequently-used-together variables can dramatically increase code readability. How do you balance the two? I was just asked to "unroll" a struct that contained 12 variables, which now makes calls to the function header monolithic; it seems poor style and I wanted to know what others thought.
How many functions do you have that uses those parameters?
If you have 4 functions that all take the same 12 parameters, it's a sign that you probably should bundle those into a cohesive set.
If you have 4 functions that use say... 8 of the parameters, then maybe those 8 should be bundled up.
But this is rather missing a little bit of the point. Bundling into a struct is not your only option. You can also break up the function so that instead of one big function needing 12 parameters, you have 8 more focused ones that need one or two parameters. Smaller functions are easier to test, easier to reuse, easier to write, easier to maintain.
Keep in mind that typically the solution is not always collapsing some of the arguments into a distinct data structure. Most of the times you should split the functions into multiple ones because probably it's the function itself that does multiple things.
I remember Uncle Bob in Clean Code saying there should be at most 2 and only in special cases 3 arguments to a function. This might be very difficult to achieve all the time (take for example functions with timeouts where the timeout and timeunit take 2 arguments).
On the other hand Code Complete is not so rigorous, saying there shouldn't be more than 7 but emphasizing on the fact that in higher-level languages this can be avoided.