I’ve been spending some time refactoring my C# code, and I’m struck by how large my parameter lists are getting for local variables, especially when you start getting several levels deep and have to pass local variables from higher up the call stack.
As an example, I have some rather complex code that uses Linq to sql. I instantiate a data context early in a procedure and use it throughout the procedure. However, after refactoring, I find that i’m passing this DC throughout all my sub-methods, along with various other state variables.
One solution, of course, is to make these local variables into member variables, but that makes the entire class non-thread safe, and when dealing with async i/o that means crippling things with locks and mutexes to make them safe.
What are your best practices when factoring in regards to local variables? Do you give in and make them members? or do you carry around the state baggage? Or do you do something else?
EDIT: I’m not sure what more detail you need. I don’t want to dump a bunch of code, because by it’s nature in order to illustrate this I have to show a very complex set of procedures.
I have a number of local variables, such as a Linq to Sql DC, various stages of processing, various stages of updates of a lot of raw data processed and written to a database.
I thought about creating a state context and passing that, but it seems kind of hackish to me, although I suppose that’s precisely what the Linq to SQL dc is.
Potentially, make them members of another type. Nested types work well here, too. That makes a lot of sense if they form a logical group, and let you write several methods using the same type.
Beyond that, we’d have to know details of what you’re doing to comment further I suspect.