I love automation. I’m pretty lazy by nature and the more I can offload to my little programmatic or robotic helpers the better. I’ll be sad the day they become self-aware and decide that it’s payback time and enslave us all.
But until that day, I’ll take advantage of every bit of automation that I can.
As a developer, it’s important for us to think hard about our code and take care in its crafting. But we’re all fallible. In the end, I’m just not smart enough to remember ALL the possible pitfalls of coding ALL OF THE TIME such as avoiding the Turkish I problem when comparing strings. If you are, more power to you!
I try to keep the number of rules I exclude to a minimum. It’s saved my ass many times, but it’s also strung me out in a harried attempt to make it happy. Nothing pleases it. Sure, when it gets ornery, it’s easy to suppress a rule. I try hard to avoid that because suppressing one violation sometimes hides another.
Here’s an example of a case that confounded me today. The following very straightforward looking code ran afoul of a code analysis rule.
public sealed class Owner : IDisposable
{
Dependency dependency;
public Owner()
{
// This is going to cause some issues.
this.dependency = new Dependency { SomeProperty = "Blah" };
}
public void Dispose()
{
this.dependency.Dispose();
}
}
public sealed class Dependency : IDisposable
{
public string SomeProperty { get; set; }
public void Dispose()
{
}
}
Code Analysis reported the following violation:
CA2000 Dispose objects before losing scope
In method 'Owner.Owner()', object '<>g__initLocal0' is not disposed along all exception paths. Call System.IDisposable.Dispose on object '<>g__initLocal0' before all references to it are out of scope.
That’s really odd. As you can see, dependency is disposed when its owner is disposed. So what’s the deal?
Can you see the problem?
Read more: haacked
QR: 
Posts
0 comments:
Post a Comment