The more I see partial classes, the more I dislike them. Maybe they're just misused a lot in this codebase, but I find them so confusing and troublesome.

I think they can be very useful, but they need to be sensibly used. I think partial classes, multiple classes in a single file, and filenames that don't correspond to the name of the class make this codebase more difficult to navigate and work on. It's something I want to incrementally resolve as I merge the projects.

In prior projects, I've used partial classes fairly successfully to split classes into logical divisions. Eg, writing an Antlr parser required a single class to handle all the nodes in the syntax tree, so having multiple partial classes to handle logical groupings of node handlers was a necessity. In this project, we have some classes that are so large (my) IDE refuses to do inspection or autocomplete on it (eg, TdsParser). If we have any hope of working on it, we'll likely need to split these up either into multiple classes or into partials.

Anyways ... I digress.

From the docshere, the first 'desirable' example is questionable (If you need 2 people in the same file at the same time, maybe you have bigger problems?), and the other 2 examples relate to code generation. I get the feeling partials were added to make development of other MS frameworks easier.

Another somewhat interesting read is here:https://stackoverflow.com/questions/3601901/when-is-it-appropriate-to-use-c-sharp-partial-classes

IMO, if your class is "too big" for a single file, then you need to re-design your class. Sometimes artifically splitting up responsibilities is for the best, even if naturally they're all the domain of a single encapsulation.

OTOH, partialmembers might be useful for reference packages. Perhaps we declare everything as partial in our ref assembly, and don't provide any definitions. Would that eliminate the need for the "throw" pattern? Food for thought.

@paulmedynski the first desirable sounds more like a holdover from the days of centralized source control (which Microsoft has much history) where having files checked out by multiple people isn't really feasible. I think if youcan't comfortably have two engineers in the same file at the same time, you've got bigger problems :)

I don't really subscribe to the "if your class/method is too big you're doing it wrong" school of thought. I think sometimes it makes sense to artificially split things up, sometimes it doesn't. But I see it more of an artform. I'm sure you'll correct me if you think my PRs are bad :P