If you’ve used any sort of static analysis on source code you may have seen a message like “Virtual method call from constructor”. In FxCop/Visual-Studio-Code-Analysis it’s CA2214 “Do not call overridable methods in constructors”. It’s “syntactically correct”; some devs have said “what could go wrong with that”. I’ve seen this problem in so many places, I’m compelled to write this post. I won’t get into one of my many pet peeves about ignoring messages like that and not educating yourself about ticking time bombs and continuing in ignorant bliss; but, I will try to make it more clear and hopefully … Continue reading “Virtual method call from constructor” What Could Go Wrong?
[Update: 25-Jan-12 5:45 pm; fixed typo] I was reminded recently of the misconceptions of the volatile modifier in C#, and I’d thought I’d pass along the recommendations of other’s that is tantamount to “avoid the volatile modifier”. The volatile modifier in C# “indicates that a field might be modified by multiple threads that are executing at the same time” . The first problem is that documentation. What does that really mean to someone developing code that uses multiple threads? Does that make the code “thread-safe”? The answer is “maybe”; the real answer is “rarely”. Most people just stick volatile on … Continue reading Avoid the volatile Modifier
One of the great sessions at Codemash was a dual-speaker session with Bill Wagner and Jon Skeet—Async from the Inside. In that session Bill and Jon describe (in great detail) the state machine that the C# compiler generates when it compiles async code involving the await keyword. When the Async CTP was released this state machine was one of the first things I noticed when I was reflecting through some generated code. I too noticed the type of the state variable (int) and wondered, at the time, if that would be an issue. All the information Bill, Jon and I … Continue reading C#, Async, Limits, oh my!
NUnit introduced a feature called Explicit Tests (a long time ago, I believe) that basically mean a test is considered tagged as Ignore unless the test name is explicitly given to the NUnit runner. This is useful if you have tests that you don’t want run all the time. Integration tests or tests highly coupled to infrastructure or circumstance come to mind… But, it’s difficult to automate these types of tests because you always have to maintain a list of test names to give to the runner. The ability of NUnit to run explicit tests aside, I don’t generally use … Continue reading “Explicit” Tests with Resharper