I mentioned earlier that I was at a developer strategy meeting last week (n fact, Markus was there too) - of course, I wasn't traveling at the time. One of the comments from that meeting was how it's very hard (read, impossible) to stick to manual code reviews. Code reviews are a great practice and certainly valuable but when push comes to shove, it's often one of the practices that seem to slip away in favor of getting things done.
Now, in Team System, you can set up all kinds of rules for checking code in to help manage this process but what can you do in FoxPro?
One idea that came to me was extending the VFPX Code Analyst tool to become "project" or "environment" specific. Yes, you can create a number of new rules to run within the code analyst and enable/disable them as needed but what would also be useful would be to allow different projects to have "different" sets of rules that they might apply to. Then set up a project hook so that when you BUILD the project, the rules automatically run, telling you what's good and what's bad.
In this sense, you now have an automated "code review" tool.
The default rules in Code Analyst handle a number of generic pieces like identifying areas for refactoring, or finding known gotchas like RETURNs within ENDWITH, similar lines of code, but consider project-specific types of rules: ensuring classes are based on a common class library, appropriate use of MESSAGEBOX, no compilation errors, etc - and the tool takes on a whole new benefit.
This is one of those things that I'm going to add to the "to do" list for the Code Analyst: built-in project hooks, and some useful project rules.
What type of rules would you want to see in your code?
VFPX - Home
Now, in Team System, you can set up all kinds of rules for checking code in to help manage this process but what can you do in FoxPro?
One idea that came to me was extending the VFPX Code Analyst tool to become "project" or "environment" specific. Yes, you can create a number of new rules to run within the code analyst and enable/disable them as needed but what would also be useful would be to allow different projects to have "different" sets of rules that they might apply to. Then set up a project hook so that when you BUILD the project, the rules automatically run, telling you what's good and what's bad.
In this sense, you now have an automated "code review" tool.
The default rules in Code Analyst handle a number of generic pieces like identifying areas for refactoring, or finding known gotchas like RETURNs within ENDWITH, similar lines of code, but consider project-specific types of rules: ensuring classes are based on a common class library, appropriate use of MESSAGEBOX, no compilation errors, etc - and the tool takes on a whole new benefit.
This is one of those things that I'm going to add to the "to do" list for the Code Analyst: built-in project hooks, and some useful project rules.
What type of rules would you want to see in your code?
VFPX - Home
Powered by ScribeFire.
Comments
Using the Project Hook is indeed a great idea.
Here are my suggestions:
Check on every event's method if there is either a NODEFAULT or a DODEFAULT() present.
Check for undeclared variables.
Thanks, and keep your great job !
Regards
Cesar