A lot of programmers will tell you there isn’t a place for quick and dirty iOS programming. While I appreciate their well-meaning enthusiasm for the craft of software engineering, I have to say this is patently incorrect.
I firmly believe there is a place for quick and dirty code.
In this post I’ll offer my opinions as to circumstances in which quick and dirty iOS programming is perfectly acceptable. I’ll also give you some suggestions as to how you can make your quickly-written programs cleaner.
(While you are here, please consider following me on twitter or adding my RSS feed to your reader. Thanks!)
What is Quick and Dirty iOS Programming?
Essentially, quick and dirty code is:
- code that was written haphazardly
- code that isn’t extensible
- code that isn’t object oriented
- code that is overly verbose
- code that is hard to maintain
- code without comments
See the Wiki article on code smells for symptoms of problematic code.
There is a famous line by Mark Twain (and perhaps others) that says, “I didn’t have time to write a short letter, so I wrote a long one instead.”
The same applies to quick and dirty code. The best solutions are often compact and simple, and it takes time to find those solutions, since they generally aren’t always obvious.
So When is Quick and Dirty Code Okay?
I contend that quick and dirty code is acceptable under the following circumstances:
- When you are learning to program
- While you are prototyping new ideas quickly
AND - When you will absolutely, positively rewrite your code later
Note: Points 2 and 3 must be taken together.
Let me elaborate on each of these.
When You Are Learning
When you are just learning to code, it is absolutely acceptable to write code however you can.
In fact if you’re waiting to start iOS programming until you know everything you need to know, you are going to be “paralyzed by perfection.” It’s just never gonna happen.
Stop being so hard on yourself, and stop caring what other people think about your code.
If you love the act of iOS programming, you will get better at it naturally over time, but you won’t get better unless you give yourself permission to make mistakes and write a lot of bad code until you learn to identify good programming practices.
While You Are Prototyping
In Robert Nystrom’s book, Game Programming Patterns, he acknowledges that “…game design requires a lot of experimentation and exploration. Especially early on, it’s common to write code that you know you’ll throw away.
Slowly written code can often kill creativity.
What’s more, until you decide which features will be included in your code, it isn’t necessarily worth your while to spend a lot of time trying to make everything perfect only to have to change it later.
When You Are Going to Rewrite Your Code
Writing bad code which serves a creative purpose is acceptable so long as you are absolutely, positively sure that you will rewrite it eventually.
It’s not easy for some people to throw away code they’ve written, however. For these people Nystrom suggests exploring creative ideas in a different programming language than your final project, so that you can’t possibly keep what you’ve written.
I have found this to be a good practice. One of my future iOS games was prototyped in Lua using the Codea app.
I found this experience to be wonderful. It allowed me to quickly test my gameplay, and when I was done, I knew the approach I needed to take in Objective-C to make it better.
Quick and Clean
So does quick code necessarily mean that the code has to be bad? No, not at all.
There are software engineers who write very good code, very quickly. Usually this comes from years of experience, but you can avoid common mistakes by refactoring your code whenever you notice some of the code smells cropping up.
You can also familiarize yourself with design patterns that are popular or that are considered industry-accepted best practices. There are many great design pattern resources on the market.
A side note on patterns: While there are certain patterns that are used most often (The Singleton, Delegation, and Model-View-Controller patterns), rest assured there are no magic patterns which are best in every situation. Game programming is very different than productivity app programming, for example, and within each sub-genre there are different patterns that are better suited for each.
Many integrated development environments (IDE’s) such as Xcode include templates for certain types of tasks. Learn when to use each type of template and don’t reinvent the wheel.
IDE’s also contain many code snippets. These are examples of best coding practices. Use them. They are your friend.
If you are going to create your own init, for example, use the init snippet in Xcode as a start.
