Besides keeping a cool head, start with the issues that are going to end up as potental bugs; the file1/file2 array assignments for example, with the lack of definition for cnts. The phone number trick will also possibly be a source of problems later.

Then refer to the code that is inefficient but where it's obvious the programmer knows a more efficient method. In this case, for example, the dealercode could be generated from the substr function, which he's used previously, with much less code and storage overhead.

Note that you shouldn't refer much to *style* (specifically the variable naming implied, the comments, or to some extent the HTML inclusion w/o using CGI's HTML) unless it's against the company policy. Style's something that is a personal feel, and issues that deal with style should not have a very large impact on speed or execution of the code.

Finally, make sure to look for *good* things in the code as well. While code critique implies "negative elements", try to find something that the programmer appears to have done well. Don't try too hard to find something good about it, of course, but if there is something that impresses you, make sure you note that.

-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com
||
"You've left the lens cap of your mind on again, Pinky" - The Brain
"I can see my house from here!"It's not what you know, but knowing how to find it if you don't know that's important