|
Or dumb, dumb, dumb. Just upgraded to VS 2012, decided to try and run the Code Analysis. Not many errors in my code (I must be awesome)
But I am definitely baffled by CA1009.
For CA1009, it is an error to declare an event handler with out using object sender as the first parameter. Well, I for one, have always thought object sender, is the worst offender of good design possible. My events are usually specifically typed to the objects that throw them. Yes, yes, that does couple the events tightly to the objects but ... no one should have to check the type of sender before using it, that design is even worse.
|
|
|
|
|
Hear hear!
Plus not many event handlers care what object raised the event.
But I hope it's a warning, not an error. Either way, it seems better suited to StyleCop or whatever, not the compiler.
|
|
|
|
|
I'm not; an event has two arguments; the object that raised the event, and some event-specific arguments derived from EventArgs . It's a predictable pattern.
Ennis Ray Lynch, Jr. wrote: My events are usually specifically typed to the objects that throw them. Yes, yes, that does couple the events tightly to the objects but ... no one should have to check the type of sender before using it, that design is even worse. I'd rather not have separate click-events for a Button .Click and a MenuItem .Click.
|
|
|
|
|
Eddy Vluggen wrote: I'd rather not have separate click-events for a Button .Click and a MenuItem .Click.
If you're using .NET 2.0 or higher, delegate contravariance[^] means that you wouldn't need separate handlers; you can assign a method which accepts an object as a parameter to a delegate where the corresponding parameter is any reference type.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
you still need to declare one event per object, even if you can use the same method to handle them.
I'm brazilian and english (well, human languages in general) aren't my best skill, so, sorry by my english. (if you want we can speak in C# or VB.Net =p)
|
|
|
|
|
All Mouse Click events come from the Control base type. To argue that object is better than Control? Funny. Further,
public delegate void SomeDeletage<T>(T t);
public event SomeDeletage<int> Foo;
Looks pretty good on paper.
|
|
|
|
|
What about events that come from FrameworkElements or DependencyObjects?
|
|
|
|
|
Ennis Ray Lynch, Jr. wrote: All Mouse Click events come from the Control base type.
Until someone comes along and makes me use a third-party library that doesn't.
Ennis Ray Lynch, Jr. wrote: To argue that object is better than Control?
We're not talking "better", but "more generalized". Anything (derived from object) can throw an event.
Ennis Ray Lynch, Jr. wrote: Looks pretty good on paper.
Isn't there an EventHandler<T> somewhere?
|
|
|
|
|
My rant is more, I would much rather have the typed event. Your third party library can use what ever it wants. I was just ranting that the "preferred method" is object sender.
|
|
|
|
|
Eddy Vluggen wrote: an event has two arguments; the object that raised the event, and
some event-specific arguments derived from EventArgs
That's not true of all events; certainly not of ones I write. I even write events that return values, because it makes sense to do so for them.
I really dislike Microsoft telling me how I should write my code
|
|
|
|
|
I learn a lot by looking at best practices. For example, I actually changed the way I code based on this
if(foo.Equals("bar"))
is worse than
if("bar".Equals(foo))
Can you guess why?
|
|
|
|
|
if (foo == null) throw new NullReferenceException();
?
Bob Dole The internet is a great way to get on the net.
2.0.82.7292 SP6a
|
|
|
|
|
Sure. Yet if foo is a string then the == operator is best (in C#). There should be very few times where you need to call Equals directly.
Ennis Ray Lynch, Jr. wrote: best practices
In my experience, most "best practices" aren't good practices.
|
|
|
|
|
I may not like or use best practices but I at least consider them (although most people assume I don't), I may have picked a poor example for my case but the point was more, hey there are some good recommendations, even if the vast majority are crap.
And, with regard to string "best-practices" I have since moved away from the "constant".equals(obj) to String.Compare(val1, val2, true [or false]) == 0 which I think is more better considering that maybe one day I may actually have to use multiple language support.
|
|
|
|
|
Ennis Ray Lynch, Jr. wrote: I at least consider them
Absolutely, you need to know your options to be able to choose one intelligently and understand the code of others.
Ennis Ray Lynch, Jr. wrote: String.Compare
Oh, well then I'm a fan of StringComparer.InvariantCultureIgnoreCase.Compare ( string , string ) and it's ilk.
Have a property or parameter of type StringComparer so the caller can provide an appropriate instance to use.
|
|
|
|
|
PIEBALDconsult wrote: That's not true of all events; certainly not of ones I write.
It wasn't about you; like I said, it's a generalization.
PIEBALDconsult wrote: I even write events that return values, because it makes sense to do so for them.
That'd be called a "callback", not an event.
Would it not be an advantage to "define" an event as "something" that passes an EventArgs ? Sounds like a simple pattern to me; a pointer to sender, and a pointer to the arguments.
PIEBALDconsult wrote: I really dislike Microsoft telling me how I should write my code
Even if they would, you would not listen. I'd recommend to most other people to consider multiple points of view, but not with you*. You have your own view, and sometimes it pays to have YOU tell how I should write my code.
Have a good 2013, I hope to disagree with you* more often.
*Learn from you
|
|
|
|
|
Eddy Vluggen wrote: it's a generalization
Yes, but it shouldn't be enforced by the compiler. I wouldn't want the compiler to dictate where I should put whitespace either.
Eddy Vluggen wrote: "callback", not an event
The syntax says event so that's what it is; but that's really just a type, conceptually it could be a callback. Just as an int could be an ID or an index.
I wouldn't see a need to have two keywords for such similar concepts. Come to think of it, this is really like the difference between functions and procedures -- functions return a value and procedures don't -- some languages (Pascal and VB for instance) make the syntactic distinction and others (C-like languages for instsance) don't, and I agree with the C way of doing it.
As an aside: VB doesn't allow event s to have a return value.
Eddy Vluggen wrote: it pays to have YOU tell how I should write my code
I hope I don't do that. CP is definitely a great place to get many points of view from others with varied experiences.
<voice type="MOB" >I say this thing with the greatest respect</voice>
|
|
|
|
|
PIEBALDconsult wrote: Yes, but it shouldn't be enforced by the compiler. I wouldn't want the compiler to dictate where I should put whitespace either. [badger,badger,badger,badger...]
Good point
PIEBALDconsult wrote: I hope I don't do that.
Until someone offers something better, I'll be abusing your DAL.
..and the rest
|
|
|
|
|