Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Comments

Corrector2 Corrector2
  • Working with DataTips in Visual Studio 2010

    Where is the high quality WMV download if a high quality MP4 download is present? How un-Microsoft of you Smiley .

  • Building Awesome Apps for Windows 7 (Session 2): Building Touch-First Applications for Windows 7

    Correct me if I'm wrong, but WPF supports touch, too.

  • Building Awesome Apps for Windows 7 (Session 1): A Lap Around the Windows API Code Pack

    How does this relate to WPF for doing the exact same thing?

  • Building Awesome Apps for Windows 7: Overview

    Wait, what's wrong with WPF for building these same managed apps without downloading any of this Windows API code pack mumbo jumbo?

  • C9 Lectures: Stephan T. Lavavej - Standard Template Library (STL), 4 of n

    Looking much better in 1.3! I'd still do more refactoring on unreachable(), but it's a whole world better than before...

  • C9 Lectures: Stephan T. Lavavej - Standard Template Library (STL), 4 of n

    Since most of the issues revolved around solve, let me be more clear in my argument:

     

    - A complex function, even if it is mostly one containing linear flow can be broken down into several simple functions in order to become more hierarchical and less linear. Let me give a simple example to elucidate my point:

     

    Instead of a long function such as:

     

    void Car::Build()

    {
       // Build the frame

       ... build the frame code

     

       // Add doors

       ... add doors code

     

       // Insert engine

       ... insert engine code

     

       // Insert transmission

       ... insert transmission code

     

       // Insert upholstery

       ... insert upholstery code

     

       // Paint the car

       ... paint the car code

     

       // Whatever else needs to be done

       ... whatever else needs to be done

    }

     

    It is much easier to see (the comments are not part of the code, I am just adding them to show what the functions being called do for the purpose of explaining my point):

     

    void Car::Build()

    {
       BuildFrame(...); // Calls AddDoors()

       AddInternalParts(...); // Calls AddEngine(), AddTransmission(), AddUphostery()?, etc...

       AddBodyParts(...); // Calls AddDoors()

       Paint(...);

    }

     

    Now the Build function is easy to eye over and comprehend. If the programmer wishes to look into detail and see how each step is actually implemented, he can go into each of the functions being called and examine them (or look at call graphs, etc...).

     

    By creating a deeper (rather than shallower) Build() function, it is much easier to comprehend in a top down (rather than bottom up) fashion. This is how most people solve and analyze problems - from an abstract problem statement to analyzing (i.e., "sweating") the details.

     

    If you:

     

    1. Break up your solve function into sub-tasks (functions)
    2. Give them meaningful names
    3. Only call these sub-tasks from within solve

    Then, it would be much easier to see what solve does as a whole and there would be no performance penalty in doing this, to boot, because these sub-tasks would probably still be gross tasks. If any of the sub-tasks are still complex, you can further decompose them into more sub-tasks.

     

    A developer reading solve would drill down to the level of interest to him, while seeing the big picture all along the way. Compare this to having to gloss over 400 lines of code, even if only looking for comments, in order to try to figure out what solve does.

     

    My two cents...

  • C9 Lectures: Stephan T. Lavavej - Standard Template Library (STL), 4 of n

    Well, he does state that the solve function, the meat of this application, will be covered in the next video, so I suppose we can take a wait and see approach. However, basic OO/structured programming tenets do not condone the use of 400 line "super-do-everything" functions, of which solve() is one. Bottom line is that we'll have to give Stephan the benefit of the doubt and let him elaborate in the next episode...

     

     

  • C9 Lectures: Stephan T. Lavavej - Standard Template Library (STL), 4 of n

    So, I opened the source file, saw a nearly 400 line solve function with minimal "island" comments and pretty much lost all interest in what the program does. Just my two cents worth... Does it really have to be this unstructured to perform? Can it be any less structured and still be instructive (/sarcasm)? Was it necessary to cram it all into one .cpp file, given that it was part of a zip archive?

     

    Just my 2 cents...

     

     

  • Techniques in Advanced .NET Debugging with John Robbins (Part 1 of 3)

    I nominate this for the worst encoding of a very important presentation to ever grace Channel 9.

  • C# 4.0 and beyond by Anders Hejlsberg

    Thanks for posting this wonderful presentation. 

     

    Please follow up with more from DevDays 2010. Also, the video and audio quality are superb! All encodings of presentations should be this good.