On: Cognitive load is what matters

[spicyusername]

You access the shared data via the struct / class reference, not as method parameters. That's the benefit.

e.g.

    foo(...):
        # Fields
        a
        b
        c
        d 
        e
        
        # Methods
        f1(f)
        f2(f)
        f3()
        ...
        f7()

[mckn1ght → spicyusername]

Moving them to a higher scope makes it harder to change anything in foo. Now anytime you want to read or write a-e you have to build the context to understand their complete lifecycles. If all the logic were smooshed together, or if it were factored into the original functions with lots of parameters, as ugly as either of them might be, you still have much more assurance about when they are initialized and changed, and the possible scopes for those events are much more obviously constrained in the code.

[spicyusername → mckn1ght]

If all those functions need all those variables, then you're either going to put them in a class, or put all those variables in something like a dict and just pass that in.

Seeing 10 variables passed in to a function is a code smell.

Whether you put in in a common class / struct or aggregate them in a dict depends on whether or not all those functions are related.

In general, your functions should not be super duper long or super duper intended. Those are also code smells that indicate you have the wrong abstractions.