Comments

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

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

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

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

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

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...

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...

 

 

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...

 

 

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

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.