Steps to reviewing your codes in IOS !

Most of the time when i am sitting to code in Xcode for IOS apps , one thing in my mind is to finish the task related to Project…Whether it is well planned or not.But the problem i always face because  of unmanaged structure of the code and project while i m debug my code.problem will create for the person who will debug the code except you.it always take more than the expected time.naturally it will take the time and the reason behind the time taking for that is i am always created file or xib file with names like xyz,abc….adding images anywhere then the project structure and no comments for methods or classes which method works for what purpose. So after a lot of time wasting in debugging my own code i Finally realise that i should change the way of coding ..so i googled few things and find some good articles on the case review for IOS. Here are the outcomes of the few articles available on Net.

• Make sure all external resources required by the project (3rd-party code, etc) are fully contained within the app, or referenced through submodules, or (best of all) included via CocoaPods. If they’re not managed in some way (e.g. CocoaPods) see if there is any documentation describing how to obtain and update these resources.
• Open the project in Xcode and build it. Make sure the project builds cleanly (with no warnings, and hopefully errors).
• Perform a static analysis in Xcode to see if any other problems show up.
• Run oclint and see if this uncovers any other problems that Xcode’s static analysis didn’t reveal.
• Examine the project structure. Do the various source code files seem to be placed in a reasonable hierarchy? The larger the project is, the more important it becomes to impose some kind of structure, in order to help outsiders find their way around.
• Does the app have unit tests or integration tests? If so, run them and make sure they complete without any failures. Bonus points if tools are in use for measuring test coverage.
• Doing all that should take several minutes for each app, regardless of the app’s size, unless you encounter major problems somewhere along the line. Finding things that are not to your liking on one or two of those points doesn’t necessarily mean that you’ve got a huge problem on your hands, but by considering your findings here you can start to get a sense of any project’s overall “smell”.
• After that, do a closer examination of each app, starting with the ones that set off the most warning flags in your head during the initial examination. You should look at every source code file (if you have the time to do so), reading through the code with all of these things in mind. You’ll probably want to take notes as you go along, when you find things that need improving.
• Are the latest Objective-C features from the past few years being used? This includes implicit accessor and instance variable synthesis, new syntactic shortcuts for creation of NSNumber/NSArray/NSDictionary, new syntax for array and dictionary indexing, etc.
• Are instance variables and properties used in a consistent way? Does the code use accessors where appropriate, keeping direct instance variable access limited to init and dealloc methods?
• Are properties declared with the correct storage semantics? (e.g. copy instead of strong for value types)
• Are good names used for classes, methods, and variables?
• Are there any classes that seem overly long? Maybe some functionality should be split into separate classes.
• Within each class, are there many methods that seem too long, or are things split up nicely? Objective-C code is, by necessity, longer than the corresponding code would be in a language like Ruby, but generally shorter is better. Anything longer than ten or fifteen lines might be worth refactoring, and anything longer than 30 or 40 lines is almost definitely in need of refactoring.
• Is the app compiled with ARC, MRR, or a mix? If not all ARC, why not?
• Does the app make good use of common Cocoa patterns, such as MVC, notifications, KVO, lazy-loading, etc? Are there any efforts underway to adopt patterns that aren’t backed by Apple, but are gaining steam in the iOS world, such as Reactive Cocoa and MVVM?
• Are there view-controllers that are overloaded with too much responsibility?
• If discrete sections of the app need to communicate with each other, how do they do so? There are multiple ways of accomplishing this (KVO, notifications, a big pile of global variables, etc), each with their own pros and cons.
• If the app is using Core Data, does the data model seem sufficiently normalized and sensible? Is the Core Data stack set up for the possibility of doing some work on a background thread? See Theo’s guide to core data concurrency for more on this.
• If not using Core Data, does the app store data using some other techniques, and if so, does it seem reasonable?
• At the other end of the spectrum, does the app skip model classes to a large extent, and just deal with things as dictionaries?
• Is the GUI created primarily using xibs, storyboards, or code?
• Is GUI layout done with constraints, the old springs’n’struts, or hard-coded frame layout?
• Does the running app have a reasonable look and feel?
• Is all networking done using asynchronous techniques, allowing the app to remain responsive?
• If a 3rd-party network framework is being used, is it a modern, supported framework, or something that’s become a dead end?
• If no 3rd-party network framework is in use, are Apple’s underlying classes being used in a good way? (There are plenty of ways to get this wrong).
• Does the app function in a fluid manner, without undesireable timeouts or obvious network lags affecting the user?
• Is the app localized for multiple languages? If so, is this done using standard iOS localisation techniques?
• If there are tricky/difficult things happening in the code, are these documented?