Calling functions from Events
-
Depends on how much they're doing. If it's just a couple lines, and won't be used anywhere else, I stick it in the event handler. If it's more substantial than that, or looks like it belongs in the model layer, or will be called from elsewhere, then I move it to a separate function.
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels)I can understand one or two lines, easily. I can't handle the mammoth 20-100 lines in an event handler. I don't know if I'm being idiosyncratic, but it drives me mad!
Craigslist Troll: litaly@comcast.net "I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson
-
Same here. If it's a couple of lines, it stays in the event handler. Otherwise, it's going into it's own method, even if, right now, it's only called by the event handler. You never know. Tomorrow, you'll find out that you now need to call it from multiple places. But, the biggest reason I break it out into its own method because of "self documenting code". Why this is such a weird concept no-a-days is beyond me. Put the code into a method and name the method something that describes what the code does! OH MY GOD! WHAT A CONCEPT!! Imagine making debugging easier! ;)
A guide to posting questions on CodeProject[^]
Dave KreskowiakI had an old school teacher that that concept was one of the first things he taught us. 1. put it in a method that can be called as a general rule 2. name the method something useful and meaningful. 3. add comments where necessary to clear things up further. The inherited code I'm looking at right now does pretty much none of the above. well over 100,000 lines of code and I have found 5 comments, one of which i paraphrase a tad bit "the order of these items must match the order of the input or bad things will happen" That is the most informative comment in the entire dang thing. and he liked names such as
public static string Code()Programming is a race between programmers trying to build bigger and better idiot proof programs, and the universe trying to build bigger and better idiots, so far... the universe is winning. A graduation ceremony is an event where the commencement speaker tells thousands of students dressed in identical caps and gowns that 'individuality' is the key to success
-
Not a question, more of a survey. How many people here always separate code from event handlers, especially Form events. I always do it, but it is driving me mad looking at and updating code that doesn't do it, written by a senior engineer. All my event handlers call functions, nothing more.
Craigslist Troll: litaly@comcast.net "I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson
I make my applications so that they have only one Event (the ApplicationStartUp Event). In this Event I code ALL logic etc. I do not use Try Catches so this is bound to go wrong somewhere. The application will close itself. When a user calls I say I even automated the UI and that everything actually went as planned (RTFM it's all in there!). My customers are happy and I am happy. The only thing that is not happy is my software, because it cannot feel emotions :D
It's an OO world.
-
I make my applications so that they have only one Event (the ApplicationStartUp Event). In this Event I code ALL logic etc. I do not use Try Catches so this is bound to go wrong somewhere. The application will close itself. When a user calls I say I even automated the UI and that everything actually went as planned (RTFM it's all in there!). My customers are happy and I am happy. The only thing that is not happy is my software, because it cannot feel emotions :D
It's an OO world.
Naerling wrote:
The only thing that is not happy is my software, because it cannot feel emotions
I wish I could upset or frustrate my software sometimes, then it might have some empathy and stop doing the same to me!
Craigslist Troll: litaly@comcast.net "I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson
-
Not a question, more of a survey. How many people here always separate code from event handlers, especially Form events. I always do it, but it is driving me mad looking at and updating code that doesn't do it, written by a senior engineer. All my event handlers call functions, nothing more.
Craigslist Troll: litaly@comcast.net "I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson
Depends. I use anonymous event handlers for events often, b/c it's useful for them to run in the scope of the calling method, and often useful to define the behaviour right there, from a readability stand point. But, for form events, I often factor them out in to a method, again for readability and reuse.
Christian Graus Driven to the arms of OSX by Vista. Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
-
Naerling wrote:
The only thing that is not happy is my software, because it cannot feel emotions
I wish I could upset or frustrate my software sometimes, then it might have some empathy and stop doing the same to me!
Craigslist Troll: litaly@comcast.net "I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson
:laugh:
It's an OO world.
-
Not a question, more of a survey. How many people here always separate code from event handlers, especially Form events. I always do it, but it is driving me mad looking at and updating code that doesn't do it, written by a senior engineer. All my event handlers call functions, nothing more.
Craigslist Troll: litaly@comcast.net "I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson
It's all relative really. You fume when you see event handlers with many lines of code. An MVC purist would cringe if he sees you calling a class method from the handler, since he would expect the call to be routed somehow to a controller or view-model. An MVVM purist would cringe at the event handler - since he'd want to see an event bound to a VM command in XAML. So don't judge the people who wrote that code because others will judge you just as sharply and just as unreasonably.
Regards, Nish
Are you addicted to CP? If so, check this out: The Code Project Forum Analyzer : Find out how much of a life you don't have! My technology blog: voidnish.wordpress.com
-
Not a question, more of a survey. How many people here always separate code from event handlers, especially Form events. I always do it, but it is driving me mad looking at and updating code that doesn't do it, written by a senior engineer. All my event handlers call functions, nothing more.
Craigslist Troll: litaly@comcast.net "I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson
I only do it if the same code can be called from non-event code.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997 -
Not a question, more of a survey. How many people here always separate code from event handlers, especially Form events. I always do it, but it is driving me mad looking at and updating code that doesn't do it, written by a senior engineer. All my event handlers call functions, nothing more.
Craigslist Troll: litaly@comcast.net "I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson
Overall it is a good idea to call functions, that way you can change the logic pretty easily and also make the code readable (assuming functions have good names). It is pretty easy these days with refactoring support to extract the code into separate methods. For instance,
void serverName_changed(object sender, EventArgs e)
{
ResetUserNameAndPassword();
}is more readable then
void serverName_changed(object sender, EventArgs e)
{
Username.Text = "";
Password.Text = ""
// Some other code usually gets very long
//}
-
Not a question, more of a survey. How many people here always separate code from event handlers, especially Form events. I always do it, but it is driving me mad looking at and updating code that doesn't do it, written by a senior engineer. All my event handlers call functions, nothing more.
Craigslist Troll: litaly@comcast.net "I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson
I'll second JSOP's method. Why cause function call overhead if you don't need to? Probably a moot point, especially if it's a button click, but something like a resize or repaint event could be called thousands of times.
- S 50 cups of coffee and you know it's on! Code, follow, or get out of the way.
-
Overall it is a good idea to call functions, that way you can change the logic pretty easily and also make the code readable (assuming functions have good names). It is pretty easy these days with refactoring support to extract the code into separate methods. For instance,
void serverName_changed(object sender, EventArgs e)
{
ResetUserNameAndPassword();
}is more readable then
void serverName_changed(object sender, EventArgs e)
{
Username.Text = "";
Password.Text = ""
// Some other code usually gets very long
//}
The worst is when you see code that calls an event handler, passing EventArgs.Empty, in order to trigger the same behaviour.
Christian Graus Driven to the arms of OSX by Vista. Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
-
Not a question, more of a survey. How many people here always separate code from event handlers, especially Form events. I always do it, but it is driving me mad looking at and updating code that doesn't do it, written by a senior engineer. All my event handlers call functions, nothing more.
Craigslist Troll: litaly@comcast.net "I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson
I'm with JSOP.
-
The worst is when you see code that calls an event handler, passing EventArgs.Empty, in order to trigger the same behaviour.
Christian Graus Driven to the arms of OSX by Vista. Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
Interesting, I did not even realise there was an EventArgs.Empty, see the things you learn at CP
Never underestimate the power of human stupidity RAH
-
Interesting, I did not even realise there was an EventArgs.Empty, see the things you learn at CP
Never underestimate the power of human stupidity RAH
It's amusingly close to useles, b/c there's no MouseEventArgs.Empty, etc, which means you can only use it where an event takes the base class, not one of the derived ones.
Christian Graus Driven to the arms of OSX by Vista. Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
-
I'll second JSOP's method. Why cause function call overhead if you don't need to? Probably a moot point, especially if it's a button click, but something like a resize or repaint event could be called thousands of times.
- S 50 cups of coffee and you know it's on! Code, follow, or get out of the way.
Yeah, but I'm usually painting custom controls in layers, so it makes more sense to put each layer in its own method. Then you can turn those layers on and off at will and replace them quite easily. Chances are you're not going to paint anything at 30 frames a second so it doesn't matter that much. If you wanted that kind of performance, I'd look to something other than GDI/GDI+.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
Depends on how much they're doing. If it's just a couple lines, and won't be used anywhere else, I stick it in the event handler. If it's more substantial than that, or looks like it belongs in the model layer, or will be called from elsewhere, then I move it to a separate function.
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels)i agree... couple of lines, not worth the effort... a lot of lines, probably will make the code a lot cleaner
-
I only do it if the same code can be called from non-event code.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997good point
-
Not a question, more of a survey. How many people here always separate code from event handlers, especially Form events. I always do it, but it is driving me mad looking at and updating code that doesn't do it, written by a senior engineer. All my event handlers call functions, nothing more.
Craigslist Troll: litaly@comcast.net "I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson
Yeah, only if large, have common code, or need to be on a separate thread, otherwise I don't sweat it.
wizardzz wrote:
All my event handlers call functions, nothing more.
That sounds needless, why not simply rename the handlers to whatever the methods are named?
-
The worst is when you see code that calls an event handler, passing EventArgs.Empty, in order to trigger the same behaviour.
Christian Graus Driven to the arms of OSX by Vista. Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
I pass
nullinstead. -
Not a question, more of a survey. How many people here always separate code from event handlers, especially Form events. I always do it, but it is driving me mad looking at and updating code that doesn't do it, written by a senior engineer. All my event handlers call functions, nothing more.
Craigslist Troll: litaly@comcast.net "I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson
There isn't any one way to split this stuff up and everyone has their own way of understanding it. My rule of thumb is that every chunk of code (function, event handler, whatever) is relatively simple to understand on it's own. Code with too many function calls can be harder to understand then 3,000 line nested if and switch statement monstrosities. If you have to go poking around in 5 or 6 files just to understand what one method does, that's a complete mess. As long as you stay away from the super long or super short clever function extreme, you should be good. As far as your team is concerned, the most important thing is that you guys roughly agree on the basics.
Curvature of the Mind now with 3D
