471,354 Members | 1,753 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,354 software developers and data experts.

Anonymous Methods

I really can not appreciate why Microsoft has introduced Anonymous
methods. It promotes quick and dirty style of programming and as I can
see it offers no advantages over normal methods.

I have spent years reviewing source code and asking people not to write
anonymous code (supported by some non-MS high level languages) and it
has made it's way to C# also!

Jan 25 '06 #1
9 1528

"John Smith" <po********@sumanthcp.plus.com> wrote in message
news:11*********************@z14g2000cwz.googlegro ups.com...
I really can not appreciate why Microsoft has introduced Anonymous
methods. It promotes quick and dirty style of programming and as I can
see it offers no advantages over normal methods.

I have spent years reviewing source code and asking people not to write
anonymous code (supported by some non-MS high level languages) and it
has made it's way to C# also!


Sounds like you are in a minority.

Even if everyone agreed with you they would still be a good idea for the
same reason that partial classes were introduced - it is better for code
generators.

Without them code generators would have to create methods that were visible
when browsing the class which introduces clutter and encourages the use of
implementation methods that are supposed to be hidden. Also anonymous
methods can be added without clashing with any "user" defined methods.

I think they are fine provided that they are only used as glue and not to
house important processing.
Jan 25 '06 #2
John,

Well, you don't have to use it. It's not being forced on you.

I, personally, find them useful. The ability to use closures is very,
very powerful, and I find it makes a good deal of what I do much easier.

I can appreciate the simplicity of the implementation in not being able
to use anonymous methods, but at the same time, I loathe the state
management required for anything overly complex, an issue that anonymous
methods helps tremendously.

Also, in C# 3.0, anonymous methods are used extensively in the form of
lambda expressions, and I can't imagine being forbidden from using that.

I do not believe that anonymous methods promote a quick, and dirty style
of programming. Like any other feature in a language or toolset, it has the
capacity to be abused (some more than others).

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"John Smith" <po********@sumanthcp.plus.com> wrote in message
news:11*********************@z14g2000cwz.googlegro ups.com...
I really can not appreciate why Microsoft has introduced Anonymous
methods. It promotes quick and dirty style of programming and as I can
see it offers no advantages over normal methods.

I have spent years reviewing source code and asking people not to write
anonymous code (supported by some non-MS high level languages) and it
has made it's way to C# also!

Jan 25 '06 #3

"John Smith" <po********@sumanthcp.plus.com> wrote in message
news:11*********************@z14g2000cwz.googlegro ups.com...
I really can not appreciate why Microsoft has introduced Anonymous
methods. It promotes quick and dirty style of programming and as I can
see it offers no advantages over normal methods.

I have spent years reviewing source code and asking people not to write
anonymous code (supported by some non-MS high level languages) and it
has made it's way to C# also!


I don't agree with you here, quite. I've never been fond of hte anoymous
class ala java, mainly because I find the declaration to be too complex and
to break up the flow of code, but anonymous methods certainly have alot of
value.

There are good uses and bad uses. I like it for simple methods that have a
highly localized value and that will be used immediatly, especially when I'm
working under a style that requires public and private methods to be
physically seperated within a source file. Consider a two line method, a
list predicate maybe:

bool ListPredicate(int item)
{
if (item > 10)
return true;
return false;
}

real simple, all in all, hardly worth a method on its own. When you run it
over a list in your own method you have a choice. Use an anonymous method to
create the method inline or create the method 50, 100, 200 lines away and
associate it via name alone. This becomes even more apparent when you have a
peppering of similar two line, single shot methods that exist strictly to
create a delegate out of them. You can also use them to kick off threads to
overcome the difference in the expected signature and the signature of hte
method you really want to call. How many one liners have you written there?

And that doesn't even show the potential benefits of local variable capture,
which does allow for different approaches that you yourself may or may not
like, but I happen to.

There are, however, certainly abuses. I don't like the idea of creating 50
line anonymous methods or using anonymous methods to subscribe to events
long term(as opposed to being used as watchdogs or somesuch) or otherwise
storing the anonymous method for future execution. Those usages do have a
bit of a quick and dirty feel to them and it is certainly harder to track
down sublte bugs. I much prefer writing a method and creating the delegate
the old fashioned way in those cases.

Could you perhaps give a more complete argument against anon. methods?
Simply stating they promote anything gives little but your opinion without
any backing logic. I am interested in why you don't like them particularly.
Jan 25 '06 #4
John Smith <po********@sumanthcp.plus.com> wrote:
I really can not appreciate why Microsoft has introduced Anonymous
methods. It promotes quick and dirty style of programming and as I can
see it offers no advantages over normal methods.


Consider a situation where you need to provide a delegate which takes
no parameters, but you effectively need some. (ThreadStart frequently
caused such problems in .NET 1.1.)

Anonymous methods allow you to simply express your needs by using the
local variables from the declaring method within the anonymous method,
with no need to declare a separate class just for the sake of
maintaining context.

Similarly, in 1.1 a method is often only used for a single delegate.
Where is the advantage in separating the code of that method from the
place where the delegate is used (eg to subscribe to an event)?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Jan 25 '06 #5
My main concern about Anon methods is that as you have agreed it can
create a mess when used to encapsulate many lines of code and the other
main worry is reusability. If you have several developers at different
intellectual levels working on a big project and they start using anon
methods ( from my experience found that they would if they could!) the
code is not only un-maintainable but severely bloated (results from
copying and pasting).

I can certainly appreciate Partial classes it a nice feature to
insulate developers from designer generated code and it can be abused
too but it is slightly easier to control than anon methods.

Jan 26 '06 #6

"John Smith" <po********@sumanthcp.plus.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...
My main concern about Anon methods is that as you have agreed it can
create a mess when used to encapsulate many lines of code and the other
main worry is reusability. If you have several developers at different
intellectual levels working on a big project and they start using anon
methods ( from my experience found that they would if they could!) the
code is not only un-maintainable but severely bloated (results from
copying and pasting).


This is the old "lowest common denominator argument".

Surely it is better to higher good programmers than to try to make bad
programmers write their bad code more clearly.

Either you are not doing code reviews or you are doing them too late.
Jan 26 '06 #7
John Smith wrote:
My main concern about Anon methods is that as you have agreed it can
create a mess when used to encapsulate many lines of code and the other
main worry is reusability. If you have several developers at different
intellectual levels working on a big project and they start using anon
methods ( from my experience found that they would if they could!) the
code is not only un-maintainable but severely bloated (results from
copying and pasting).


That indicates a failure of communication and convention though.

There are many things which can be abused - just define a convention
which states what's acceptable and unacceptable, and enforce it. This
is of course easier to do if you're already using code reviews or pair
programming.

In my view the benefits (in terms of readability, mostly) of anonymous
methods outweigh the potential problems.

Jon

Jan 26 '06 #8
A convention/rule is easier to write down than to 'enforce'. If you are
looking at 40 developers churning out code, anon methods add extra
bullet points to the code-reviewers list and every bullet point costs
money (this is a tough one to automate). About hiring good programmers
in big numbers - I don't think it is possible given the timescales 'we'
are faced with. Just to hire three contractors we spent more than 3
weeks! and unfortunately every week costs the project money.

I have found that the only effective way to control a varied
cross-section of developers from writing bad code was not by code
reviews but by using the strong arm. By strong arm I mean using tools
that provide a very rigid framework to developers thus limiting the
scope of programming. This was highly successful in producing
consistent and very easily portable source code but came with
additional costs of tools and high employee attrition ( some developers
felt their artistic license was being deined).

So my message would be not to use anon methods unless it is a very
small team (max 2) and it is absoultely essential.

Well, it has been an interestnig discussion. Thanks everybody.

Jan 26 '06 #9

"John Smith" <po********@sumanthcp.plus.com> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...
A convention/rule is easier to write down than to 'enforce'. If you are
looking at 40 developers churning out code, anon methods add extra
bullet points to the code-reviewers list and every bullet point costs
money (this is a tough one to automate). About hiring good programmers
in big numbers - I don't think it is possible given the timescales 'we'
are faced with. Just to hire three contractors we spent more than 3
weeks! and unfortunately every week costs the project money.

You don't need to hire good programmers in big numbers - You DO need to hire
bad programmers in big numbers and then your good programmers get tied up
supervising or clearing up after the bad ones.
I have found that the only effective way to control a varied
cross-section of developers from writing bad code was not by code
reviews but by using the strong arm. By strong arm I mean using tools
that provide a very rigid framework to developers thus limiting the
scope of programming. This was highly successful in producing
consistent and very easily portable source code but came with
additional costs of tools and high employee attrition ( some developers
felt their artistic license was being deined).
Let me guess.....That would be the good ones.
So my message would be not to use anon methods unless it is a very
small team (max 2) and it is absoultely essential.


I think I can safely say that I wouldn't want to work for your company.

I am curious about why you do. I can only assume that you enjoy the power.
[I'm not trying to flame anyone here I just honestly can't see what the
appeal might be]

Jan 26 '06 #10

This discussion thread is closed

Replies have been disabled for this discussion.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.