Re: C# Command to Wait a Specified Period of Time

Tech-Archive recommends: Fix windows errors by optimizing your registry


"Scott Roberts" <sroberts@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:OB52bOLWIHA.6140@xxxxxxxxxxxxxxxxxxxxxxx

"Peter Duniho" <NpOeStPeAdM@xxxxxxxxxxxxxxxx> wrote in message news:op.t41rkrxw8jd0ej@xxxxxxxxxxxxxxxxxxxxxxx
On Wed, 16 Jan 2008 15:07:58 -0800, Scott Roberts <sroberts@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

Well, there you go. My cursory observation of your code gave a completely incorrect impression as to when the code would execute.

How would defining a method elsewhere and using that to instantiate a delegate have helped that situation?

It wouldn't, but a simple iterative method that executes when it is called would.

To be more clear, which of these two code blocks would a college intern be more likely to read, understand, and modify without introducing errors?

public List<Person> FilterByAge(List<Person> input,
int ageLimit)
{
List<Person> result = new List<Person>();
foreach (Person p in input)
if (p.Age < ageLimit)
result.Add(p);
return result;
}

Or this one:

public List<Person> FilterByAge(List<Person> input,
int ageLimit)
{
return input.Where(delegate (Person person)
{ return person.Age < ageLimit; }
);
}


One uses a standard "for loop", a basic construct available in pretty much every programming language since assembly. The other uses newer and more advanced C#-specific constructs that are probably still completely foreign to 90% (or more) of the current C# community.

The second construct is more elegant, concise, and most probably more efficient. Peter and Jon, you both clearly have a much greater and deeper understanding of C# than I (and the vast majority of other C# programmers) do, but that is *exactly* what makes my opinion on "readability" more salient than yours. I'm sure that once one gains experience with these newer language constructs that they do enhance "readability" - for the people who know and use them. But the fact of the matter is that, at least in my experience, the vast majority of people making a living as a "programmer" still struggle with objects and events, let alone delegates, anonymous methods, and the like. Perhaps that is an indictment against me and my knowledge (or lack thereof) of C#. I've heard it argued before that if it's part of the language specification then a "C# programmer" should know how to read & use it. But I'll tell you right now that there are a bazillion C# and ..Net language features that I don't know and will never know. And you and I both know that this is true of the vast majority of programmers out there.

So you are more than welcome to continue writing elegant, concise, efficient code until the cows come home. I hope that you do. But don't go around saying that a code block consisting of delegates and anonymous methods is "more readable" than a simple "for loop". And please note that I said *simple* "for loop". Don't waste your time fabricating yet another artificial example of a complex iterative loop that is easily solved with another construct. The point here is not that a more advanced construct can't be more readable in some situations; the point is that it's not more readable to a wider audience *for the simple example provided*.

Since Jon has a penchant for ignoring context and missing points, let me spell out the points I am NOT making:

I am NOT saying that advanced language constructs have no place in C#.

I am NOT saying that advanced language constructs cannot be more readable - even to a novice programmer - in some situations.

I am certainly NOT saying that simple language constructs are always more efficient than advanced ones.

I am NOT saying that readability must triumph over elegance and efficiency in all cases.


And the point I am making:

I AM saying that given a relatively simple task, using a ubiquitous construct (such as a "for loop") will be more *readable* to a wider audience than using a more advanced construct.

.

Relevant Pages

  • Re: C# Command to Wait a Specified Period of Time
    ... But the key to use the query syntax is you don't do the for each loop yourself, instead you state what you want, not how to do it. ... I'm sure that once one gains experience with these newer language constructs that they do enhance "readability" - for the people who know and use them. ... But don't go around saying that a code block consisting of delegates and anonymous methods is "more readable" than a simple "for loop". ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Code Behind vs not
    ... > maintainability are certainly high priority, ... >> The best code is both readable and maintainable and balances efficency. ... >> understanding is a result of readability. ... >> long time delphi programmer, I prefer VS to borland in this arena). ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Code Behind vs not
    ... maintainability are certainly high priority, ... Because truly efficent code in NEVER readable, ... > understanding is a result of readability. ... > long time delphi programmer, I prefer VS to borland in this arena). ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)
    ... Python get's my vote for most readable in this case. ... > That's actually my biggest problem with Perl. ... to improve code readability, ... > programmer, who wasn't completely confused by their ...
    (comp.lang.ada)
  • Re: should i write keywords uppercase?
    ... programmer seems to develop his own style. ... and plenty of good commenting is quite desirable. ... I imagine you'll also get advice on other readability issues, ... > How do professional fortran-coder write? ...
    (comp.lang.fortran)