I don't know about any standardized process here, but what I usually do is:
- Create a text report (Word converted to PDF) that lists all "improvment" points found in the code.
- The points are listed by file.
- For each point, I have a nomenclature to target its area: [P]erformance, [M]aintanibility, [S]ecurity, [D]eployment, [E]xecution error may occur.
- Each point is also attributed a criticity level (marked as a colored left border): black (critical, needs immediate fixing), red (important, need attention), orange (low impact, cosmetic, may be looked at later to get a perfect code!) and green (for very good code/structure to be signaled). My customers love this.
- At the end of the report, I may include a conclusion with a general text, a recapitulative table, and details on some common problems found.
Please, also note the following:
- Your mission is to note every improvment point (I also include very good approaches to be fair, when I find some), even if you know you'd have done the same "errors" by lack of time or else.
- The task you've been assigned is very tedious. Reading other's code is boring, especially when you need to read carrefully all the files! Try to schedule some pauses in your work!
- One thing you can do is to use the find tool to quickly get basic/common problems the code may contain: use of .Items
on big lists, opening of SPSite
(check disposal), caching of SP objects, use of contextual objects in event receivers, closing of contextual objects, axcess or mis-uses of elevated sections, usage of display names, ...