3

I'm fairly new to programming and wanted to start programming more efficiently. Try as I may I often find myself straying from the MVC model.

I was wondering are there any tips or methods in keeping your code organized when coding in xcode objc? To be more specific (I know you guys like that :) I want to

  1. Be able to write libraries or self-containing code that can bring from one project to another
  2. Share my code with others as open sourced projects
  3. Prevent myself from writing messy code that does not follow proper structure
Improve this question
3
  • If you are new to programming, you should start by learning the principles and practices of OOP, instead of jumping in the deep end. Commented Sep 10, 2012 at 4:24
  • Thanks for your quick response. I've written a couple apps actually. I've read pretty much all of the apple documentation and watched the WWDC videos. I think I understand the basic principles but I'm having trouble putting them into practice. I was wondering if there were some best practices that the more experienced programmers here could pass onto a newbie like myself. Commented Sep 10, 2012 at 4:28
  • @VXtreme if that is the best option yes. Mainly I want to be able to reuse code and speed up my development. I find myself getting bogged down in the details and then getting disorganized. From what I understand static libraries are best to update code but can be pain to reference properly. Commented Sep 11, 2012 at 2:03

2 Answers 2

Reset to default
5
  • Use a high warning level. Build cleanly.
  • Remove all static analyzer issues.
  • Write some unit tests.
  • Keep the public interfaces small.
  • Specify your library's dependencies (e.g. minimum SDK versions and dependent libraries).
  • Compile against multiple/supported OS versions regularly.
  • Learn to create and manage static library targets. This is all you should need to support and reuse the library in another project (unless you drag external resources into the picture, which becomes a pain).
  • No global state (e.g. singletons, global variables).
  • Be precise about support in multithreaded contexts (more commonly, that concurrency shall be the client's responsibility).
  • Document your public interface (maybe your private one too…).
  • Define a precise and uniform error model.
  • You can never have enough error detection.
  • Set very high standards -- Build them for reuse as reference implementations.
  • Determine the granularity of the libraries early on. These should be very small and focused.
  • Consider using C or C++ implementations for your backend/core libraries (that stuff can be stripped).
  • Do establish and specify any prefixes for your library's objc classes and categories. Use good prefixes too.
  • Minimize visible dependencies (e.g. don't #import tons of frameworks which could be hidden).
  • Be sure it compiles without the client needing to add additional #imports.
  • Don't rely on clients putting things in specific places, or that resources will have specific names.
  • Be very conservative about memory consumption and execution costs.
  • No leaks.
  • No zombies.
  • No slow blocking operations on the main thread.
  • Don't publish something until it's been well tested, and has been stable for some time. Bugs break clients' code, then they are less likely to reuse your library if it keeps breaking their program.
  • Study, use, and learn from good libraries.
  • Ask somebody (ideally, who's more experienced than you) to review your code.
  • Do use/exercise the libraries wherever appropriate in your projects.
  • Fix bugs before adding features.

Don't let that scare you -- it can be really fun, and you can learn a lot in the process.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

Thank you! I wrote each one of these points down in my notebook and elaborated to help me remember this awesome checklist. It's absolutely fun to code and see a app come together (it can be absolutely maddening). I wanted to take a step back and review my habits to see where I could improve. Cheers.
@a4suited you're welcome. learning to write good libraries can take years, but it's nice to have programs which work reliably in many contexts -- just keep an eye out for code duplication and consider that duplicate code belongs among your library of libraries :)
4

There are a number of ways you can reuse code:

  • Store the code in a common directory and include that directory in your projects. Simple, but can have versioning issues.
  • Create a separate project which builds a static iOS library and then create a framework. More complex to setup because it involves scripting to build the framework directory structure. But easy to use in other projects and can handle versioning and device/simulator combined libs.
  • Create a separate project which builds a static iOS library and then include this as a subproject in other projects. Avoids having to build frameworks and the results can be more optimised.

That's the basic 3, there are of course a number of variations on these and how you go about them. A lot of what you decide to do is going to come down to who you are going to do this for. For example I like sub projects for my own code, but for code I want to make available for others, I think frameworks are better. even if they are more work to create. Plus I can then wrap them up with docsets of the api documentation and upload the whole lot as a DMG to github for others to download.

Improve this answer

1 Comment

thanks! I believe you're right when you suggest frameworks but that might be something I will tackle down the road. I try my hardest just to write clean code let alone a scripted framework. This is definitely something I look to tackle at some point though. Thanks for the tips.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.