Code Reviews

For the last months I’ve been doing a lot of Objective-C. Got a new job and only focus on iOS development. Since I am the new guy in the team, I learn a lot by looking at code from my peers (and looking at code in general). And even though I have a lot of ActionScript experience under my belt, I’m starting fresh with Objective-C. Frustrating at times, awesome most of the time. I love being the new guy. I get to ask dumb questions, can still write silly code and make a lot of beginners mistakes. And challenge my peers by having Shoshin or beginners mind.

One of the things I really love is code-reviews by my peers, they are mandatory at the place I work. They basically go through my code and comment on it when I fuck up or make dumb mistakes. Lately I had to return the reviewing favor.

Looking through code of my co-workers and myself I noticed a couple of things and thought it would make a good bit for an article. I’ll go through as much of the bad stuff I can find and discuss them here. As habits are hard to change, get in the habit of changing them as soon as you see them in your own code. This is by no means a definitive list and if you have suggestions for more, let me know in the comments.

1. Commented Code
Since you use a VCS like Git or SVN, there is absolutely no need to leave commented code in your source files since you can always revert. So remove it.

2. Duplicate Code / KISS
If you have a lot of duplicate code all over the place – you are doing it wrong. KISS and refactor (see point 6.)

3. NSLogs
Since Apple defines logging *only* for errors, a better way to get information from your app is by utilizing your debugger. There have been numerous articles about not using NSLog in (production) code and why it’s better to use a breakpoint. The cool thing about breakpoints in XCode is that you can use non-breaking breakpoints that send a message to the output window.

4. Retarded and/or short unreadable variable names
No matter what language you write code in, you always need to make sure it is readable. For your team members or for yourself when you come back to a project a year from now. This includes the correct naming of variables. Since Objective-C is by itself a very verbose language, variable name tend to have the same tendency. Using myReallyLongVariableName is oke, since compilers nowadays are optimized to deal with this. Verbosity and readability over brevity and difficulty to read code.

5. Small is beautiful
Just like an app or program, methods need to do one thing only and do that one thing well. Like the UNIX philosophy.  That’s what I’m taught and still believe. Don’t bloat your methods with doing six things. This makes it very difficult to read, understand and debug. Small is beautiful.

6. OOP
What I see *a lot* is that people don’t know how to use proper OO. Not knowing how to extend classes or know how to design to a protocol (Objective-C’s term for interfaces) is basic stuff. Don’t be afraid to ask your peers, even if you’ve are an (iOS) senior.

7. Design Patterns
While design patterns are not a magical, ready made solution or a silver bullet if you will, I do advise you to get a proper book on design patterns and learn about Model View Controller (MVC), Key Value Observation (KVO) / Observers and Delegation. These are the fundamentals of iOS programming.

8. Refactoring
The problem with writing code is that there is always ego involved. Even in ego-less programming (MUST READ!). That one brilliant solution you created for that one project will look like crap to another team member. People see things in different ways and that is oke. People do things to solve problems. Don’t try to rewrite everything just because it doesn’t look proper to you, try to put yourself in their shoes when they wrote this piece of code you are looking at. And breathe.

9. Lose the Ego
Reality check: Your code is not you. What? Your code is not you. It is just a solution to a problem, even though sometimes a very good solution. Don’t think you are the only one that can have good solutions. I don’t. (Well I actually do, sometimes – but I’m learning) The best solution come from unexpected corners or people. Even veterans make thinking mistakes, I know I do. And lose the ego. Realizing that makes you grow and makes better software.

10. Take responsibility
The next person that says “Nah that wasn’t me that wrote this” will get a kick in the groin. Seriously. I truly believe developers in general need to take responsibility for the code they create. Not taking responsibility is not believing what you wrote in the first place. You do care about your code right? Otherwise you are in this for the wrong reasons. Making a mistake is not the worst thing that can happen, it’s just a piece of code we are taking about. So have some balls.

BONUS. My debugging mantra

As I already mentioned on Twitter some time ago; Bugs are communication errors between you and the machine and can be fixed by asking ‘what do you think i said and why do you think that?’. Taking this step back can help you debug faster._

_

So. Embrace change, be open, don’t be cocky, loose the ego, look with children’s eyes, have a shoshin mind and enjoy what you are doing – only then will you grow as a coder.