Why I love yield return

Aside from it's memory efficient as compared to eagerly populating list: http://ideone.com/QxU7Sn

..it saves us a lot of boilerplate codes too, there was once in C#'s life that there's no yield return magic yet, we have to contend with iterator design pattern, and that entails a lot of boilerplates code: http://www.ienablemuch.com/2010/12/lazy-loading-fibonacci.html


Long and short of why yield return is so awesome:
http://www.ienablemuch.com/2012/08/use-components-that-uses-yield-return.html


Use yield return when returning IValidatableObect, or any list for that matter. There's no need to create a List<ValidationResult>
http://www.ienablemuch.com/2011/07/ivalidatableobject-client-side.html

Find changeset number by comment

Use VS commandline tool:
Start > Programs > Microsoft Visual Studio 2012 > Developer Tools > Developer Command Prompt for VS2012


How to find broken promises:



For some strange reason, the Visual Studio 2012 plugin Find Changeset By Comment has installation error when I add it on Visual Studio, so I have to use a commandline tool

So that's how I manage to find codes I can't remember the changeset number

That's also how I find the changesets of a code review when the engineer forgot to include the changeset numbers of their code

To automate that task install AutoHotkey, then include this script. #c means Windows+C

#c::
InputBox, UserInput, View Changeset List, Please enter a comment,,,,,,,,div.*by.*zero
Run %comspec% /k ""C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\Tools\VsDevCmd.bat" & tf history $/ /noprompt /recursive | findstr /i /r /c:"%UserInput%""
return

So when you press Windows+C this will appear:




The script then runs the TFS commandline tool. The VS plugin can't be installed on my dev machine, but at least I can find changeset anytime even Visual Studio is not open, so I got that goin' for me, which is nice

Programming without the programming language

I agree with Jon Skeet's assertion that it's better to know the idiomatic way to program with the programming language. There are cases though that using something fancy language operation like compounding a value to another variable, makes the solution look non-intuitive




I forgot how my old Fibonacci solution was intuitive to me:

static IEnumerable<int> Fibonacci()
{
    int a = 0,  b = 1;
                         
    for(;;)
    {        
        yield return a;
        int n = a;
        a += b;
        b = n;          
    }
}

Perhaps making a language-driven solution e.g., increment, makes something non-intuitive in the long run and hard to reason out


When I tried to plot the values of that old fibonacci solution, this is how a bit jumbled-looking the values are, read this from up to down, then left to right

A 0 1 1 2 3 5
B 1 0 1 1 2 3
Y 0 1 1 2 3 5
N 0 1 1 2 3 5

Then when I wanted to recall that fibonacci code off the top of my head, sadly I can't, so I try solve it with a pen and a paper, following is what I came up with, and it's a little different from the old solution I've made before. This is one of few instances where not having eidetic or retentive memory is good, the brain is flushing out old memories and it is stimulated to be creative on coming up with new and elegant approaches. Read the following from up to down, then left to right


Pencil-and-paper solution:

A 0 1 1 2 3 5
B 1 1 2 3 5 8
Y 0 1 1 2 3 5
N 1 2 3 5 8 13

The values' progression look symmetrical and it maps nicely to code too:

static IEnumerable<int> Fibonacci()
{
    int a = 0, b = 1;
      
    for(;;) 
    {      
        yield return a;
        int n = a + b;
        a = b;
        b = n;   
    }       
}

The only drawback of not having eidetic memory is your stock knowledge tend to decrease or get rusty. But who needs eidetic memory when you can store your knowledge to blog? Another advantage of having a blog is you can compare if your new approach improved