One of the main things is to have everything will committed so you know what are data fields and what is data processing variables. i.e. loop control. What IF/Case Test are for.
Use the simplest Function that does what you need if it gives the value you need without extra processing. Fewer chances to make errors with fewer parameters.
2 of 2 people found this helpful
You may want to establish coding standards first (how to name fields, scripts, layouts, what to use not use in scripting techniques like passing parameters, making field/table names safe in ExecuteSQL(),...)
That way you have something to focus on during code review.
Typically when we do code review we pick a particular use case from a solution, let the developer explain the goal and then go through the code/layouts/schema line by line and check assumptions etc.
Code review is different than QA. In QA, every bit of functionality is tested to see if it works, and the code inspected to see how robust it is and whether it handles all possible error scenarios.