Opinion Wanted: Calling an Event Handler

[Fao, Sean]

A guy I know never refactors his code and insists on putting everything
in an event handler. For example, he does some initialization of a
DataGrid in the ItemDataBound event handler (which is actually the wrong
place for his initialization, anyhow, because it has *nothing* to do
with the items being bound, but that's another topic, altogether). At
any rate, some times, it's necessary to "refresh" the control to take
advantage of an update that occurred and he'll manually call the event
handler, passing it the current event handlers sender and EventArgs
parameters. It drives me absolutely nuts and I explain to him that his
code needs to be refactored; but, he insists that "it works" so he
refuses to change his ways.

Technically, he's right --it does work. But, in my opinion, it's sloppy
and could benefit greatly from a little time spent on refactoring.

What do you guys think?

--
Sean

[Kevin Spencer]

Hi Sean,

You are correct. However, convincing your colleague may prove to be a
daunting task, esp. if you do not have authority over him. Check out the
following web site on the Microsoft MSDN:

http://msdn.microsoft.com/practices/

This is a wealth of information about best practices, good design, and good
architecture.

Why are best practices important? Best practices are developed for the
purpose of making software cost less to develop and maintain.
Poorly-designed software becomes an albatross on the neck of the company
that develops it. It is much more expensive to fix problems than to prevent
them. Preventing them entails an expenditure of some resources towards
education, and time in the development process. But the greatest expense to
any software company comes from support. And poorly-developed software is
expensive to support. Another cost factor is the inevitable
upgrade/extension of the software. Well-designed software is much easier to
extend and upgrade, because it is built with this in mind.

If you do not have authority over your colleague, show your supervisor this
resource (link above), and let him/her do his/her job. If you do have
authority over this person, make best practices a policy in your
organization. And be sure to read up on these best practices for yourself.

And remember, the requirement is not for you to be proven right (e.g. prove
you are correct in a debate with your colleague). The requirement is for you
to be an asset to your organization.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Who is Mighty Abbott?
A twin turret scalawag.

"Fao, Sean" <en**********@y ahoo.comI-WANT-NO-SPAM> wrote in message
news:u7******** ******@TK2MSFTN GP10.phx.gbl...

A guy I know never refactors his code and insists on putting everything in
an event handler. For example, he does some initialization of a DataGrid
in the ItemDataBound event handler (which is actually the wrong place for
his initialization, anyhow, because it has *nothing* to do with the items
being bound, but that's another topic, altogether). At any rate, some
times, it's necessary to "refresh" the control to take advantage of an
update that occurred and he'll manually call the event handler, passing it
the current event handlers sender and EventArgs parameters. It drives me
absolutely nuts and I explain to him that his code needs to be refactored;
but, he insists that "it works" so he refuses to change his ways.

Technically, he's right --it does work. But, in my opinion, it's sloppy
and could benefit greatly from a little time spent on refactoring.

What do you guys think?

--
Sean

[Bruce Wood]

"It works" are the words of a greenhorn.

A university professor of mine asked a question (and gave the answer)
that I'll never forget. He asked,

"What is the purpose of writing code?"

Lots of us gave answers, "To make the computer perform some task," etc.
etc. His answer:

"To make it clear to the next guy who reads that code how you solved
the problem."

My professor's claim was simple: if the only point is to make the
computer do something, then why not just write it in assembly language?
Or machine language? The computer understands that just as well as it
understands C#, as it were. The answer is that it's very difficult for
other programmers coming along afterward to discover what you did and
why.

This leads into one of my "rules of programming":

"A mediocre standard is better than no standard at all."

or

"Your cool new way of doing whatever had better be ten times better
than the usual way, or by definition it sucks, because if you're going
to force someone else to spend extra time to figure out what you did,
it had better be worth the trouble."

Hacking out funky code "that works" costs your employer extra, because
it will be more expensive to maintain. Any moron can (given enough
time) make a program "work." A good programmer will make it work, and
make it clear how it works so that it's easy to fix and modify in the
future. That's what separates the professionals from the dilletantes.

[Dale]

Get your whole team to pitch in and buy the guy a copy of Martin Fowler's book.
--
Dale Preston
MCAD C#
MCSE, MCDBA
"Fao, Sean" wrote:

A guy I know never refactors his code and insists on putting everything
in an event handler. For example, he does some initialization of a
DataGrid in the ItemDataBound event handler (which is actually the wrong
place for his initialization, anyhow, because it has *nothing* to do
with the items being bound, but that's another topic, altogether). At
any rate, some times, it's necessary to "refresh" the control to take
advantage of an update that occurred and he'll manually call the event
handler, passing it the current event handlers sender and EventArgs
parameters. It drives me absolutely nuts and I explain to him that his
code needs to be refactored; but, he insists that "it works" so he
refuses to change his ways.

Technically, he's right --it does work. But, in my opinion, it's sloppy
and could benefit greatly from a little time spent on refactoring.

What do you guys think?

--
Sean

[Peter Bromberg [C# MVP]]

Bruce,
I'm gonna save that piece and put it in my blog or whatever at the
appropriate time and with proper credit. Elegant!
Peter

--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com


"Bruce Wood" wrote:

"It works" are the words of a greenhorn.

A university professor of mine asked a question (and gave the answer)
that I'll never forget. He asked,

"What is the purpose of writing code?"

Lots of us gave answers, "To make the computer perform some task," etc.
etc. His answer:

"To make it clear to the next guy who reads that code how you solved
the problem."

My professor's claim was simple: if the only point is to make the
computer do something, then why not just write it in assembly language?
Or machine language? The computer understands that just as well as it
understands C#, as it were. The answer is that it's very difficult for
other programmers coming along afterward to discover what you did and
why.

This leads into one of my "rules of programming":

"A mediocre standard is better than no standard at all."

or

"Your cool new way of doing whatever had better be ten times better
than the usual way, or by definition it sucks, because if you're going
to force someone else to spend extra time to figure out what you did,
it had better be worth the trouble."

Hacking out funky code "that works" costs your employer extra, because
it will be more expensive to maintain. Any moron can (given enough
time) make a program "work." A good programmer will make it work, and
make it clear how it works so that it's easy to fix and modify in the
future. That's what separates the professionals from the dilletantes.

[Bruce Wood]

Or Code Complete 2 by Steve McConnell.

[Nick Hounsome]

"Fao, Sean" <en**********@y ahoo.comI-WANT-NO-SPAM> wrote in message
news:u7******** ******@TK2MSFTN GP10.phx.gbl...

A guy I know never refactors his code and insists on putting everything in
an event handler. For example, he does some initialization of a DataGrid
in the ItemDataBound event handler (which is actually the wrong place for
his initialization, anyhow, because it has *nothing* to do with the items
being bound, but that's another topic, altogether). At any rate, some
times, it's necessary to "refresh" the control to take advantage of an
update that occurred and he'll manually call the event handler, passing it
the current event handlers sender and EventArgs parameters. It drives me
absolutely nuts and I explain to him that his code needs to be refactored;
but, he insists that "it works" so he refuses to change his ways.

Technically, he's right --it does work. But, in my opinion, it's sloppy
and could benefit greatly from a little time spent on refactoring.

What do you guys think?

Apart from anything else this doesn't work well with high level modelling
since the relevent events are not high level events and it is therefore
impossible to model the designed operations properly.

eg. You will have a use case for something like "Add user". This will
typically require a form with an OK button on it but the design should be at
the level of AddUser() NOT OkButtonClicked () because the former shows a
clear link to the use case and is comprehensible to a non-programmer whereas
the latter shows no link and is too low level.

[Fao, Sean]

Hi Kevin,

I apologize for the delay in my response.

You are correct. However, convincing your colleague may prove to be a
daunting task, esp. if you do not have authority over him. Check out the
following web site on the Microsoft MSDN:

http://msdn.microsoft.com/practices/
I was actually unaware of this site. It's full of great resources.
Thank you very much for the link.
This is a wealth of information about best practices, good design, and good
architecture.

Why are best practices important? Best practices are developed for the
purpose of making software cost less to develop and maintain.
Poorly-designed software becomes an albatross on the neck of the company
that develops it. It is much more expensive to fix problems than to prevent
them. Preventing them entails an expenditure of some resources towards
education, and time in the development process. But the greatest expense to
any software company comes from support. And poorly-developed software is
expensive to support. Another cost factor is the inevitable
upgrade/extension of the software. Well-designed software is much easier to
extend and upgrade, because it is built with this in mind.
I can definitely understand where you're coming from. This particular
persons code is a lot more confusing because his techniques are so
unpredictable and unstandardized.
And remember, the requirement is not for you to be proven right (e.g. prove
you are correct in a debate with your colleague). The requirement is for you
to be an asset to your organization.

I hope I didn't come across as arrogant in my original post because I
was definitely inquiring with good intentions. I've been known to be
somewhat obsessive with certain things (I don't know many
developers/engineers that don't prefer to have things done their way ;-)
), so I like to seek outside opinions when I feel there's a chance I
might be subliminally trying to force my way onto somebody else.

Thank you again for your response,

--
Sean

[Fao, Sean]

Peter Bromberg [C# MVP] wrote:

Bruce,
I'm gonna save that piece and put it in my blog or whatever at the
appropriate time and with proper credit. Elegant!
Peter

I agree. That was *very* well said.

Thank you for the response,

--
Sean

[Fao, Sean]

Nick Hounsome wrote:

Apart from anything else this doesn't work well with high level modelling
since the relevent events are not high level events and it is therefore
impossible to model the designed operations properly.

eg. You will have a use case for something like "Add user". This will
typically require a form with an OK button on it but the design should be at
the level of AddUser() NOT OkButtonClicked () because the former shows a
clear link to the use case and is comprehensible to a non-programmer whereas
the latter shows no link and is too low level.

I admit that I've been somewhat lazy in the past with documentation (I
usually rely on my code and any comments as documentation), so I didn't
even consider the havoc this would create when documenting. This is
valid argument, however, as I'm starting to document my code better.

Thank you for the insight,

--
Sean