Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

iOS Developing Good Programming Habits

Will0827

Will0827

macrumors regular
Original poster
Aug 11, 2008
155
17
I just got done with a 3 and half month course on iOS programming, obviously that isn't enough time to touch on everything but, i have developed a good base on to which continue to add on to. The course covered from learning C all the way through using json to get data from the internet. My main question is where is a good place to start reading on things that should be hard wired. I know some methods for some classes have to be read up on to see exactly how they work and when best to use them, but i sometimes catch myself making some small mistakes which sometimes take me several hours to finally figure out. I guess with more time of just getting used to coding i will be able to spot them faster, but i would also like to hear what more experience coders have to say as far little things to develop good habits. Thanks guys.
 
The wiki link gave some insight with what i was reffering to in my question, i guess also simple mistakes new programmers often make and in general good habits to get into that help avoiding those mistakes and progress better.
 
You might want to review the Coding Guidelines for Cocoa.

Quick tip I use: never name the instance variable that backs a property with the same name. I usually use an underscored variation. As in:
Code: 
@synthesize listArray = _listArray;
This ensures you use the proper accessor (via self.) and not reference the ivar directly.

Plus: Learn to use the debugger on good code before learning it on bad code.
 
style and indentation is one thing. It is our code, so can you follow your rules about indentation.

Stuff that helped me is to use descriptive variable names and don't' abbreviate them. No "int i" but "int loopCounter"

Avoid "For i=" loops. Forin loops take away the hassle of sorting out the end condition.

Code: 
it(!someLogicTest)
is a pain to troubleshoot. Maybe it's me getting old but
Code: 
 if(NO == someLogicTest)
is much easier to understand. Having the NO in "NO == someLogicTest" come first will help to avoid the occasional mistake between "=" and "==".

Give all your if's an else, give all your switch's an default: At least consider them when planning the program flow.

There is probably more, but can't think of it now.
 
Will, I understand your question because I learn and create these small apps and I wonder if I am using good coding habits too.

The first objective C program I wrote from my mac, I wrote all in 1 class and use the [self someMthod]; to call the different methods. Someone pointed out that I have clearly missed the the point of using objects. But even though I did not use different objects to perform tasks the program still worked I thought.

The next app I worked on for the iphone I had different ViewControllers but I wrote all the code in the viewControllers from fetching Plists to parsing data. Everything for that view was in the viewController. If another ViewController needed to access the same files I would just copy paste those methods into the new ViewController.

After all that, people pointed out that I should not do that but have a model MVC design. That the ViewController should kind of pass thing to the view and I should process data someplace else.

So now days, I might still be wrong, but I use 1 large class which is a subClass of NSObject that I write all my methods that all of my ViewControllers would need to access. An example if 2 objects need access to the same Property List that contains an NSDictionary, I just have 1 method written that returns an NSDictionary from that property list. I just instantiate that object, send a message to that instance method and NSDictionary is returned for my view to use.

I don't know if this method is right way of doing it or a good habit, but it seems pretty clean and it works. I'll wait until someone points out my flaws and adjust again.
 
One habit I've gotten in to, not sure if good or bad, is to over indent Comments and NSLog calls.

That way you can read down the left for code, read down the right for notes you've left for what code should be doing. The trick seems to be to get enough tabs so your eye can pick up the line and read the column, but not so many that it's too hard to read them together. Great thing with text colouring most of the right hand column is green so NSLogs stand out.
 
*choose good variable names
*do error checking often
*work out what you want to do first with pencil & paper (handy having an exercise book)
*run often debug & release builds
 
Thanks for taking some time out and replying guys very appreciated. I will be taking a look at the book posted and since i have made the thread i kept searching and looking for some articles and just practiced writing small programs with not much use just to keep myself in a good programming mind state. I feel that with the constant reading that i do and practice time i spend in xcode i'll be able to get better into the swing of things and advance more.
 
Two more suggestions:
1. Learn the debugger.
2. Write unit tests.

The purpose: to see what's really happening in your program.
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back