1. Yes. 2. Yes for interface members and abstract members, where the actual logic is going to be implemented in an implementation. Occasionally on a concrete member if the logic is not straightforward and there are specific conditions that are reasonably verifiable. 3. Yes, I use the Contract class. 4. No.

My most memorable subtle bug experience dates back about 14 years. I had just coded a fairly complex piece of logic, but I had worked through the design and coding very meticulously and was certain it would work. But of course it didn't. On a second careful review of the design and code, everything still seemed to be in order. With no good debugger in the coding environment, I began peppering my code with debugging statements to narrow in on the bug. Then I began replacing complex sections of code with simple statements which of course no longer implemented my logic but still demonstrated the bug. After two full days of debugging effort, my broken code was finally reduced to one simple statement along the lines of... print(1+1) ... which produced a result of 3 !?!? After staring at that for quite some time, I ran Windows calculator and typed in "1+1=", and was again greeted with a 3. The fix? After replacing a failed math coprocessor chip, my original code worked just fine.

I should have given full credit to the authors and publisher when quoting that book. "Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries" by Krzysztof Cwalina and Brad Abrams published by Addison-Wesley as part of the Microsoft .NET Development Series

The official .NET Framework guidelines are documented in the book "Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries". This book includes the guideline to use Pascal case or camel case for acronyms more than two characters, but before getting to that it says, "In general, it is important to avoid using acronyms in identifier names unless they are in common usage and are immediately understandable to anyone who might use the framework." (Section 3.2.1. Capitalizing Acronyms). In an annotation in that same section, co-author Brad Abrams acknowledges that the Framework does not consistently follow these guidelines, and states, "For the most part, our customers have seen the places in which we have diverged from these guidelines (for even the best excuse) as warts in the Framework."