|
Simple Code Reviews Help Ace TRUE BREW® Certification
February 2005 by Lauren E. Darcey
Code reviews are best done by a third party – someone who hasn’t been staring at the code and can give it a fresh look. However, sometimes schedules are tight, development teams are small (especially in wireless), and you want to submit now, now, now!
A little review upfront can make all the difference between a pass and a failure, save time and money, and increase your company’s certification batting average. So get yourself into the appropriate mindset - critical but fair.
Here are just a couple of code-related areas worth reviewing prior to submission for TRUE BREW® testing:
- Address All TODO’s and TBD’s
I always get my team into the habit of leaving comments in the code for unaddressed items. These comments are often simple - just a TODO or a TBD (to be determined), with the coder's initials and a short note about what needs to be done or addressed. Sometimes its an unimplemented feature, and sometimes it's just a question or a verification or an assertion that has not yet been made. Regardless, one of the last things to do before a submission is to search the code for just these sorts of comments - and either address them. If you can comfortably delete them all, then you're ready to go.
- If You Start It, Stop It
Make sure you manage all your resources properly. For example, if you use timers in your application, make sure that you always stop them at the appropriate times. Search for matching stop calls for every start call. The same goes for network API calls, and other such session-type activities.
- If You Load It, Release It
With the tools QUALCOMM provides, there is absolutely no excuse for you to have memory and resource leaks in your code. Follow an "Acquire Resources Late, Release Early" policy, so that your memory footprint is as small as possible, and you're less likely to forget to free up things. This is harder to review for, but start with searching for words like "Load".
- Check Appropriate Return Codes
I know sample code often glosses over checking function return codes and acting appropriately. Yes, I know it clutters up your code, but you should still use them. You should be able to look at the code and be confident that if some function fails, your app will handle it - gracefully - even if that means shutting itself down. Give some thought to when your application is most vulnerable to catastrophic errors - loading and saving are good examples. Scrutinize these areas especially.
- Validate Assertions and Avoid Crashes
I generally like to see assertions made at the beginning of a function, to validate the parameters. Don't assume that Load calls will always be successful. This is especially relevant when checking pointers for NULL.
- Review Suspend & Resume behavior for All Application States
Check over your suspend and resume code. Are you making saving off any pending information on suspend? Do you resume and send the user to the same state as before? Make sure EVERY state knows what to do on suspend and resume. One sneaky test case that sometimes needs special attention is when the user suspends and resumes in the middle of something that has not been committed, and then cancels the action.
- Handle All Control Events; Document Where You Derive From Standard Behavior
The Application Specification is a crucial part of the NSTL submission process. It includes a description of all controls used, how they work, and if they deviate from standard control behavior. Make sure you're handling all the events for each control you use - whether it's a standard BREW control or one of your own custom ones. Review the App Spec and make sure what's going on in the code matches what's been documented.
- More Application Specification Vetting
Is your Application spec up to date with your latest code changes? Especially relating to timer functionality, errors and exceptions, common behavior, as well as input restrictions.
- Verify your MIF files
And finally, one of the most common NSTL rejections around... Your MIF must reflect your application specification, especially in terms of App Name, Version Number, and Permissions. Make sure the version of the MIF, App Spec, and your application about box and splash screen are exactly the same.
So you've likely found some of these items easy to address, and some are near impossible to address so late in the game. Well, you can learn from the exercise. Mostly, this involves sitting down with your team and developing a few coding practices - especially with regard to resource allocation, comments, assertion validation and NULL checking. Trust me, each time you go through this process, it makes life easier for everyone and your next application with be better for it.
For more information about TRUE BREW® Certification, check out the
QUALCOMM BREW® Website.
|
|
