Welcome to the Treehouse Community

Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.

Looking to learn something new?

Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.

Start your free trial

iOS

Process Outline Guide

I am confident that a guide or reference template for project structuring would be beneficial to everyone learning to program, in any language. Having helped teach Microsoft Excel business courses in college, (frameworks, lengthy functions, object oriented models), I am confident that the Team Treehouse Community would benefit greatly if one was created for us, and for aspiring developers in the future.

Being that the IDEs are constantly changing, the frameworks being updated daily, and each developer having his||her own style... Developing a sound understanding of a particular language is nearly impossible and extremely frustrating for anyone that can't grasp the "bigger picture" of what's going on behind each and every method call, declaration and segue.

What I am requesting:

Does anyone have a GUIDE they follow, or Team Treehouse, could you provide us with a Checklist-lIke outline of what to be sure to include in EVERY project? The structure of the project is important, but I think it would be more important to include the steps to build with the CODE requirements/expectations in each section of a project.

Ray Wenderlich's team has put together a great syntax reference guide, https://github.com/raywenderlich/objective-c-style-guide/#cgrect-functions but it isn't clear where to implement the various:

classes objects delegates properties methods variables.

Basic Example:

  1. MVC structured
  • Data Source
  • Delegation
  1. Screens Expected for UI
  • IB (storyboards, xibs...)
  1. ViewControllers for each screen
  • Interface files
  • Implementation Files

4: Controls for Views

  • Methods for Outlets and Actions
  • Variables

And so on.....

I would develop my own, and have in a sense, but I don't feel that I have a sound enough understanding quite yet.

Thanks and sorry for the lengthy post.

Keep developing, keep dreaming and don't stop wanting to learn more!

  • Chris

You bring up a good point. I'd would like to see what treehouse comes up with.

I have been using the Sam Soffe style guide here https://gist.github.com/soffes/812796 but I also use Apple's as well here: https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CodingGuidelines/CodingGuidelines.html

1 Answer

Aaron, I appreciate your response! I just went through the non-Apple style guide you provided and find it interesting to see others' points of views. Checkout the Link I provided in my post, it's been updated for iOS 7 and it is very code friendly, not to mention there's a list at the bottom of all the other major style guides.

On a different note, coding styles are going to differ dev to dev, so why do beginners learn from a:

  • "let's learn how to make make cement, before building our first skyscraper"

approach, rather than a bigger picture approach:

  • "Let's talk about what every building must have, the types of buildings we intend on building, then learn about the cement, framing, and other building components required."

This is more what I was inferring when asking for an outline:

  1. Make sure your View Controller, of whichever type, includes these..... methods and these..... properties.

  2. Here are the things we often do using this ViewController: A)..B)..C)..D)..

  3. Apps like: (this app, that app, and this app) use A, B, D.... while C, replaces D for apps like these apps...

Just a structured approach to what is required and what isn't. What methods are being used and why. Why one might call a method, from another class, in viewDidLoad rather than viewWillAppear.