It should go without saying, but comments should be written with the code, not afterward.

Once a module is coded, it should be run through a code analyzer such as pc-Lint and CodeCheck.  These vital tools will help insure coding standards, but more importantly, find serious memory and flow issues within the code itself.  One might think the compilers and Bounds-checker style debuggers/monitors should do this, but tools like pc-Lint are actually far superior in what they can detect.

An important facet of writing a  module is to test it.  Since the tests area already written, this should be a very simple matter, though the tests themselves may need debugging to insure their accuracy.

Developers should also step through all of their code to check both coverage and proper flow control and processing.  This is most easily done by running the tests, since the tests should exercise every piece of written code.  If they do not, add more tests until everything is tested and operating as expected.  It is vitally important that developers step through their code as much as possible, because this is the last chance to catch odd flow control issues and other problems before check-in.

Obviously, any new code should be tested within the entire application framework whenever possible.  This should usually including running all the major application unit tests (and maybe some regression tests) to insure the new code has not broken something else.  In addition, developers should usually run additional testing tools such as BoundsChecker to look for additional issues such as memory violations - this is particularly key when running expansive unit tests, as issues are most likely to show up under those exhaustive tests.

Once the code is fully tested, it can be checked in for others to use.