1

We're going to do some peer reviews for our iOS projects. We're kind of inexperienced at reviewing each other's codes. The iOS developers attending the reviews will be from other projects, since generally one person handles one client project in the company.

I know there are some questions on SO about the things you're looking for when you're reviewing someone else's code. I want to ask this question specifically for iOS projects. I mean, besides the general points for code quality, what are the things that you consider when reviewing an iOS code?

aslı
  • 757
  • 1
  • 5
  • 11
  • How to do a code review and what makes good iOS code are really two separate questions. If you know both, you can easily put them together. – JeffO Jan 20 '12 at 22:32

2 Answers2

2

What happens in a code review doesn't depend on the type of project. The general things you look for are the same in iOS projects as Android projects as the embedded systems code for avionics. However, the difference is in the structure. Mission and life critical code typically has more structured reviews involving more people and more time. Non-critical code might be reviewed using something as simple as an over-the-shoulder check or another person just skimming the code and providing comments.

The first thing to address is what you are going to review, which is addressed in another question here on Programmers. In theory, you want to review everything. In practice, you need to prioritize what gets reviewed based on a number of factors ranging from the likelihood that a module contains defects (based on the complexity of the logic) to the amount of use a code segment has (if it's used often, it's probably more important to review, since a defect there would be exposed in more places).

The things that you are looking for in a code review are those things that can't be found through automated means. Check for code style, logic errors that might not be tested for, suspicious boundary conditions, race conditions, off-by-one-errors. Code reviews can also encompass the test cases, and you can make sure that the tests that have been written are value-adding, meaning that you don't have multiple tests covering the exact same conditions and that tests appropriately cover edge cases.

You might also be interested in two questions about what a code review looks like and effective strategies for performing a code review.

Community
  • 1
Thomas Owens
  • 79,623
  • 18
  • 192
  • 283
1

Make sure you have a workflow put in place to catch as many problems as possible before you review code. So, as a minimum, make sure show warnings as errors is set on, and the static analyzer runs every time they compile.

If you're expecting certain standards in the code, put together a house coding style that devs should adhere to. For example, that all iVars should have a @property declared, and @synthesize iVar = _iVar

For iOS code, lack of understanding of memory management is an issue with inexperienced developers, so pay particular attention to that. E.g. are all retained properties released in the dealloc?

Do they understand Cocoa design patterns? Is there proper separation of model, view, controller? Have they implemented delegate protocols where appropriate?

This one's a particular bugbear, but if I see [[UIApplication sharedApplication] delegate] anywhere in the code it would raise a red flag!

I'll add more as I think of them!!

Ashley Mills
  • 713
  • 1
  • 5
  • 10