How to Conduct Code Reviews

A good post to start with is here: https://css-tricks.com/code-review-etiquette/

I thought I’d share my own “wisdom” on the subject, regarding what I do:

1) I conduct the code review to cover the good, the bad, and the ugly.
2) I ask myself the question “if I had to maintain this code, what would I want to know?”
3) I ask others to speak up if they see anything in my algorithms or structure that I’m doing wrong.
4) I often present alternate implementations with pros and cons (for example, using metadata and reflection vs. imperative code, using LINQ vs. “old style” coding.)
5) And most importantly, I don’t lead code reviews of other people’s code, I ask them to lead a code review of their own code.

The result is a learning experience for everyone (including me) and particularly the discovery of algorithm deficiencies or where comments would really be helpful.

My View of WPF

To tell the truth I’ve never worked with a larger pile of crap than WPF. It is a complicated, HTML duplicating, half baked, non updating, patterns over killing … anomaly … that provides zero productivity boost over WinForms and I’m still seeking for a cult that actually divides programming between a C# writing programmer and a XAML writing graphical designer. That’ll be the day. They should’ve detached WinForms from underlying Windows and extended it instead. WinForms is a result of three decades of event driven GUI development. Bloody Bill’s Che Guevaras threw it away for a poor experiment in complicating what has already been simplified in the 90ties. — Tomaž Štih I couldn’t have said it better!