Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've spent the past 2 years teaching myself and taking classes on object oriented programming. I have done quite a bit of Java programming, and lately I've been spending a lot of time doing objective-c. I really enjoy programming, but one thing that I have noticed (with some frustration) is that I'm not amazing at finding elegant solutions to problems.

I'm beginning to notice that it isn't enough to just solve a problem, but that the way you approach and implement a solution says a lot about you as a developer and depth of your knowledge and understanding.

Being that I am looking to make a career out of iOS development (I'm still in college), I want to be sure that I am doing everything I can to learn elegance, as opposed to just getting it done.

Case in point: For one of my first programming projects for school (this was a long time ago!), we needed to populate arrays with tons of information. I went through and added each element line by line just hard coding the index! When the TA came by he laughed at me and was like: "Why didn't you just use a for-loop?" and I thought to myself, well who cares? It works doesn't it?

My Question to iOS devs out there: What are some things that I can study/try to implement to increase the elegancy of my design habits? What are examples of things that are often done in the app development world by rookies that just shouldn't be done? Instead of just being able to throw a quick and dirty hack job of a solution together, I want to be able to consistently come up with awesome ways to solve problems! And I've realized that those types of solutions don't always come quickly to me.

Is this skill something that can only be acquired through experience and doing it wrong tons of times before you realize that there is a better way? Are there any areas that you can recommend I try to cover and make a point of understanding?

While I am happy that I can keep up with many of the q's posted to sites like this, I get frustrated when I see some that are just in a whole different universe! I want to close the gap, and so I am throwing this out there to any who may be interested/able to help.



migration rejected from Aug 11 '14 at 19:40

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as too broad by MichaelT, Bart van Ingen Schenau, Kilian Foth, GlenH7, gnat Aug 11 '14 at 19:40

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

It is nice to know that you like iPhone programming but this is no place to discuss it. This is a place for programmers to solve technical issues. Please Read What kind of questions should I not ask here? in Stackoverflows FAQs. I think you just found a wrong place to discuss this. – PARTH Mar 26 '11 at 4:30

While I am happy that I can keep up with many of the q's posted to sites like this

Are you sure? You haven't answered a single question. You don't get feedback that way.

If you have a solution for a question you should post it. If you don't know a solution and the problem is interesting for you try to find one.

If it's wrong somebody will downvote your answer. With a bit of luck there will be a comment that tells you what's wrong.

If it's ugly somebody might post a comment and tell you what you can do to make it better.

Come back after some days and check the other answers. Try to figure out what's better or worse in the other answers.

Answering questions improves your skill much faster than only reading. I can't count the new things I learned because I've answered a question.

You have to show your code to become a better programmer. Show it in stackoverflow answers or (kind of) show it in a product that is actually used.
If you are into open source create a project.

[rant] Judging on the code quality of many iOS open source projects you can do that right now, no need to write well designed, elegant, usable or even code without obvious bugs (that show you a nice yellow warning bubble) [/rant]

But you should definitely have an app in the app store. Every iOS developer that can write code that gets things done without crashes should have one. Nobody can see your ugly code anyway.
After I published my first app I learned more about good code design in the first month than I learned in the year I spent with reading tutorials, blogs, books and documentation.

But I learned it the hard way. At the beginning each improvement I added needed a huge refactoring (aka delete 90%) of the code. Because I used so many "it works, so what?" solutions.

It's one thing to read about Model-View-Controller. It's another thing to realize that your current implementation is crap because it violates MVC everywhere and you can't do this and that because of your bad design.

And only after you've changed 30 methods that are invoked by NSNotifications and post other NSNotifications you will realize that the "NSNotification is awesome!!!!11" thought you had a year ago was kind of wrong.

Learning by doing, and if doing means writing bad code then do it.
I doubt that anybody (besides Jon Skeet) can write elegant code without writing hundreds of thousands of lines of ugly code first.


Stephen, this is a fantastic question! I've been, like you, trying to improve my chops as an iOS developer for the past few years, and I think that I've improved a lot (I still have a ways to go!).

When searching for elegance, you come up against the old problem of whether something that makes your code shorter is simply too scary to be elegant. Case in point: I wrote a category on NSObject to release all retained properties of an object automatically (to simplify -dealloc implementations). This was certainly a very elegant thing, but it was also super scary: it caused some strange bugs (which I suspect were affected by subtleties in the Objective-C runtime implementation, as well as the compiler), and eventually had to be pulled out. I suppose my point is that there's got to be a balance between elegance and learning to not make things too clever.

So, my rule of thumb for elegance:

  1. Usually, elegance means less code.
  2. Usually, elegance means you can understand it quickly.
  3. Sometimes, elegance means more code (but less scary magic).

The most important thing is that you get really confident with Objective-C so that you can learn to ignore the people who say that X is not possible (or useful), or so that you can listen to them. If you're not confident with your tools, you'll be cowed by people who are less inventive than you are.

Find a role-model who writes code like you imagine Jesus would write code! Try to copy them. Eventually, you'll get sick of their style and maybe even go in the opposite direction. The point is that you experience different, valid styles of doing things. In the end, even if you come out somewhat agnostic, you'll possess the tools to make elegant solutions, no matter the constraints put upon you by your environment (depending on the team you're working with, you may change the type of solution you propose).

I think that my answer has been a bit rambly, but I hope that at least some of it was helpful. Best of luck!


Great apps are designed, not "just" coded.

But it sounds like your programming education also needs much added reading in basic algorithms and design patterns.