Hi I’m Cris, iOS Developer in KLabCyscorpions. In this post, I want to share with you my presentation on Code Review guidelines for iOS. But, what is Code Review? According to Wikipedia: “Code Review is systematic examination (often known as peer review) of computer source code. It is intended to find and fix mistakes overlooked in the initial development phase, improving both the overall quality of software and the developers’ skills. Reviews are done in various forms such as pair programming, informal walkthroughs, and formal inspections.” Want to review code? Then First things first! For you to review code effectively, you need the basic know-how of reviewing code as both the developer and the reviewer. These slides will give some guidelines on how to think in both these roles when reviewing code.

1. Code Review
Cris Uy

2. Agenda
• Goals
• Types of Code Review
• Tips for Developers during Code Review
• Tips for Reviewers during Code Review
• General Guidelines
• Control Structures
• Error Handling
• Resource Leaks
• Performance
• Maintainability and Reusability

3. Goal

4. • To spot and fix defects early in the process

5. • Helps to maintain a level of consistency in
design and implementation

6. • Better shared understanding of the code
base as team members learn from each
other

7. Types of Code
Review

8. Formal Code Review
• Involves software developers meeting
together and reviewing relevant code line by
line many times taking the opportunity to
analyze printed copies of the materials

9. Peer Code Review
• Can be done over the shoulder where the
reviewer looks over the author’s shoulder as
the other goes through the code
• Or can be done via email or version control
system like Git and online conference

10. Tips for Developers
during Code Review

11. • The primary reviewer is the author.
• You

12. • Create a checklist for yourself of the
things that the code reviews tend to
focus on

13. • Understand and accept that you
will make mistakes

14. • No matter how much your
knowledge is, someone else will
always know more than you

15. • Don’t rewrite code without
consultation

16. • The only constant thing in this
world is change

17. • Fight for what you believe, but
gracefully accept defeat

18. • Please note that review meetings
are not problem solving meetings

19. • Helping to maintain the coding
standards

20. Tips for Reviewers
during Code Review

21. • Critique code instead of people – be
kind to the coder, not to the code

22. • Treat people who know less than
you with respect, deference and
patience

23. • Ask questions rather than make
statements

24. • Avoid the why questions

25. • Remember to praise

26. • Make sure you have good coding
standards to reference

27. • Remember that there is often more
than one way to approach a
solution

28. • You should not rush through a code
review – but also, you need to do it
promptly

29. • Review fewer than 200 – 400 lines
of code at a time

30. General Guidelines

31. • Is the code following coding
guidelines and naming
conventions?
• Reviewer should have a reference
for coding guidelines and
conventions

32. • Are all compiler warnings fixed?

33. • Are there leftover code for
testing/development?

34. • Is the code complexity under the maximum
allowable threshold for a given metric?
• *a class is less than 500 lines
• *a method does not contain more than 15
control structures

35. Control Structures

36. • Check for infinite loops?

37. • Does the loop iterate the correct number of
times?

38. Error Handling

39. • Does the code check for null exceptions?

40. • Does the code check for array out of bounds
exceptions?

41. Resource Leaks

42. • Are all allocated memory freed?

43. • Do all classes perform thorough cleanup on
its destructor (dealloc)?

44. • Are all notification observers, event listeners,
message receivers or gesture recognizers
removed when not needed?

45. • Does the code accurately keep track of
reference counting?

46. Performance

47. • Are you using blocking system calls when
performance is involved?

48. • Will the same data be reloaded often?

49. • Will caching data improve performance?

50. • Is a large number of big objects being
created and destroyed in a small amount of
time?

51. • Will reusing objects improve performance?

52. • Was this optimization really needed?

53. Maintainability and
Reusability

54. • Is the code using magic numbers and magic
strings?

55. • Does the code comply with the DRY (Don’t
Repeat Yourself) principle?

56. Thank you!