Code Review for iOS

3,252 views

Published on

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.

Published in: Education, Technology, Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,252
On SlideShare
0
From Embeds
0
Number of Embeds
13
Actions
Shares
0
Downloads
103
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Code Review for iOS

  1. 1. Code Review Cris Uy
  2. 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. 3. Goal
  4. 4. • To spot and fix defects early in the process
  5. 5. • Helps to maintain a level of consistency in design and implementation
  6. 6. • Better shared understanding of the code base as team members learn from each other
  7. 7. Types of Code Review
  8. 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. 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. 10. Tips for Developers during Code Review
  11. 11. • The primary reviewer is the author. • You
  12. 12. • Create a checklist for yourself of the things that the code reviews tend to focus on
  13. 13. • Understand and accept that you will make mistakes
  14. 14. • No matter how much your knowledge is, someone else will always know more than you
  15. 15. • Don’t rewrite code without consultation
  16. 16. • The only constant thing in this world is change
  17. 17. • Fight for what you believe, but gracefully accept defeat
  18. 18. • Please note that review meetings are not problem solving meetings
  19. 19. • Helping to maintain the coding standards
  20. 20. Tips for Reviewers during Code Review
  21. 21. • Critique code instead of people – be kind to the coder, not to the code
  22. 22. • Treat people who know less than you with respect, deference and patience
  23. 23. • Ask questions rather than make statements
  24. 24. • Avoid the why questions
  25. 25. • Remember to praise
  26. 26. • Make sure you have good coding standards to reference
  27. 27. • Remember that there is often more than one way to approach a solution
  28. 28. • You should not rush through a code review – but also, you need to do it promptly
  29. 29. • Review fewer than 200 – 400 lines of code at a time
  30. 30. General Guidelines
  31. 31. • Is the code following coding guidelines and naming conventions? • Reviewer should have a reference for coding guidelines and conventions
  32. 32. • Are all compiler warnings fixed?
  33. 33. • Are there leftover code for testing/development?
  34. 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. 35. Control Structures
  36. 36. • Check for infinite loops?
  37. 37. • Does the loop iterate the correct number of times?
  38. 38. Error Handling
  39. 39. • Does the code check for null exceptions?
  40. 40. • Does the code check for array out of bounds exceptions?
  41. 41. Resource Leaks
  42. 42. • Are all allocated memory freed?
  43. 43. • Do all classes perform thorough cleanup on its destructor (dealloc)?
  44. 44. • Are all notification observers, event listeners, message receivers or gesture recognizers removed when not needed?
  45. 45. • Does the code accurately keep track of reference counting?
  46. 46. Performance
  47. 47. • Are you using blocking system calls when performance is involved?
  48. 48. • Will the same data be reloaded often?
  49. 49. • Will caching data improve performance?
  50. 50. • Is a large number of big objects being created and destroyed in a small amount of time?
  51. 51. • Will reusing objects improve performance?
  52. 52. • Was this optimization really needed?
  53. 53. Maintainability and Reusability
  54. 54. • Is the code using magic numbers and magic strings?
  55. 55. • Does the code comply with the DRY (Don’t Repeat Yourself) principle?
  56. 56. Thank you!

×