<p> Code Review Guidelines: DO: DON’T: 1) Use a UML diagram to 1) Make personal comments about understand the dependencies in the authors or use inappropriate the code and consider how levity in describing flaws you appropriate they are. may find 2) Address underlying structural 2) Take criticisms as personal issues attacks—the point of a code 3) Look for areas where someone review is to let you improve your who does not work with the code coding style as well as the constantly cannot understand particular piece of code being what the code is doing ( look for examined good documentation habits) 3) Get involved in prolonged 4) Look for areas that will make arguments about possible code hard to maintain corrections 5) Look for areas that will make 4) Ignore the comments people code less flexible make about your code 6) Look for areas that will reduce 5) Comment on truly trivial the scalability of code problems (like two spaces where 7) Look for encapsulation violations there should be one) (such as unnecessary getters/setters or dependencies) 8) Be as specific as possible in describing where you think problems are. 9) Describe problems as specifically as possible (ie “There is no documentation indicating the purpose of functions or the relationships between files x, y and z” instead of “the documentation was poor and I had no idea what the code did”) 10) Comment on things that are done particularly well (do you want to hear nothing but what is wrong with your code or would you rather get some praise, too?) 11) Suggest constructive solutions to problems you find 12) Think about how likely it is that your code suffers similar flaws and what you can do to correct it 13) Make the appropriate corrections to your code after the review</p>