In C# 3.0 Microsoft introduced support for something called partial methods.
Do you use them? Can you describe how and why?
Do you consider the use of partial methods good programming practice, or not?
edit: Two people downvoted the question? I find that puzzling and amusing. Should I not be asking this?
Partial methods are primarily useful for extension of the behaviour of tool generated code without cost in either runtime evaluation or user visible code where such extensibility is not used.
As such their use is sensible and to be encouraged where it is necessary, but such occasions will be relatively uncommon for most users (who are not writing tools to generate code). If you are writing such a tool then consideration should be given to where people may which to interact with the flow of your generated code, and whether such usage cannot be handled easily through event like mechanisms while achieving your intended performance and usability goals. Events are inherently multicast and such structure may be inherently against the intended design of the API. Alternatively a complex return value, or interaction with ref/out parameters might be necessary, finally the extension may be complex/fragile despite its utility and as such only the partial class implementer may be in a position to adequately handle this. All these reasons have their niche, if not being common and partial methods can effectively solve them.
Consumers implementing partial methods should use them as the tool generated code dictates (if an extension point is supplied and you need it, use it). To avoid doing this because one feels that the feature is confusing would be poor use of the language and API since this is clearly the intended extension point.
Microsoft programming culture has always favored a looser "duct tape" approach. This goes back at least as far as the Quick BASIC vs. Turbo Pascal wars. Microsoft languages allow shortcuts. Take, for example delegates: a delegate is basically an interface that you forgot to design in. Partial methods are just more of the same.
The title of your question refer's to Edsger Dijkstra's infamous letter to CACM and this is very apt. The Dijkstra letter was the official starting gun for the structured programming wars. Personally I don't think you will find wisdom by advocating either a strutured or an unstructured path in all situations.
I've always thought this conflict was a product of the differences in the engineering vs. computer science perspectives. Eary Microsoft programmers were programming bare metal all day. After you've written enough assembler, the dictates of structured programming seem a bit silly.
The tradeoff boils down to: would you like enough rope to hang yourself, or would you like to be forced to rewrite parts of your architecture to satisfy inflexibility of the language? A disiplined team can write good code in either environment, and there's no universal right answer.
Back to the quesiton at hand: I don't believe partial methods are a great language feature, but if they were necessary to make LINQ work, they're definitely worth tolerating.
I had occasion to use a partial method on a class library I wrote. It was possible to compile the library into one of several different versions, with the use of defined constants, that would compile-in or compile-out various blocks of function.
But littering the code with #if / #endif for all the combinations of options, cross with Compact Framework as well as desktop framework, led to some confusing stuff.
I used partial methods to sort of simplify that piece - as sort of invisible or implicit #if/#endif. This is similar to the way they're used in LINQ, as I understand it.
On the other hand I don't, at runtime, add in these methods, as LINQ would, or does. Rather than the linq model, where there are separable assemblies, and when combined you get extra function, in my class lib, there is a single DLL built for each combination of options. This is to make deployment and consumption easier.
Partial classes make C# and VB work more like C and C++ where you can scatter the code that implements a class across different files as you see fit. Their main purpose is cleanly support visual designers for things like WPF. I consider this a good use for partial classes.
Another use I have seen is to split up a large source file into logical parts. For example class BigForm might span the BigForm-BillingInfo.cs, BigForm-ShippingInfo.cs, and BigForm-LineItems.cs files. This is usually a poor use of partial classes, because refactoring into multiple classes or controls is better OOP design (for reusability, etc.).
Partial classes are a very useful feature, for example, when you have a client and a server and both of them need to share data types for business object persistence. You have your regular class server side, you expose it client side with your web service and if you want to decorate things client side, very beautifully, you can make a partial version of your class (client side you have a code generated version of the server version through proxy generation etc.).
I just wanted to say this example, as I make an extended use of partial feature, nowadays, working on a silverlight project, persisting disconnected objects :)
//Sorry for not noticing that the question refers explicitly to methods. Partial methods are very useful for weaving code functionality in event handlers, auto generated in certain scenarios.