I am a huge proponent of code walkthroughs. There are many benefits:
- Cross training team members on development language
- Cross training team members on business the software serves
- Lower bug counts per release
- Enforcement of coding standards
- Flushing out potential inefficiencies in the code
- Communication of development techniques
A little over a week ago I blogged about VFP Macro Substitution Techniques and I received a couple of private emails offering suggestions for the code examples I posted. One in particular was very helpful from Sergey Berezniker (major VFP guru, VFP MVP, and UT posting bot {g}). He introduced me to the GETPEM() function. So instead of this code:
lcPropertyValue = loPickedControl.&lcProperty;
I can use this code:
lcPropertyValue = GETPEM(loPickedControl, lcProperty)
As Sergey points out, the macro substitution code will be slower. Now I could argue the time savings will be immeasurable to the human mind, but the code is way more readable. This is what code walkthroughs are all about!
I have seen developers get very defensive on the constructive criticism side of the code walkthrough. I on the other hand welcome suggestions to make me a better developer. This morning I did a code walkthrough with my son who is subcontracting for me on a Web project. I know little-to-nothing about PHP, yet I was able to make some subtle suggestions to his code to make the application better.
It is important when doing code walkthroughs to not attack other developers. This is one of the simple golden rule things. Treat other developers with the same respect you want when you are the developer who is in the “hot seat.” I regularly and informally walk through code for other developers, especially those I am mentoring. You would be amazed how much I have learned by doing this.
So thanks again Sergey, and others who were kind enough to nudge me with suggestions. I am a better developer today because you took the time to do so.