I'm still very new to programming and I want to write the cleanest code possible.

This may sound like a silly question, but what order should I put my methods in? Functionally of course it doesn't matter, but layout it makes a huge difference. So say we have the following code in one class:

-(void)testCreateProjectWithStartDate {
    [self setUpTestCreateProjectWithStartDate];

-(void)setUpTestCreateProjectWithStartDate {
    testMOC = [self setUpInMemoryStore];
    [self mockOutXMLStoreForInMemoryStore];

- (NSManagedObjectContext *)setUpInMemoryStore {
    NSPersistentStoreCoordinator *coordMock = [self pscMock];

- (NSPersistentStoreCoordinator *)pscMock {

-(void)mockOutXMLStoreForInMemoryStore {

Do I have the methods ordered in the order that they are called? What if a method is called from two places within a class?

This code snippet looks a complete mess to me - it's very confusing to have to skip about as much as this just to figure out what is a very simple flow.

What order of methods would make more sense?

Was it helpful?


You have multiple options to group your methods:

  • By functionality (i.e. methods which need each other are close together)
  • By visibility (e.g. public methods declared in the interface come first)
  • By name (i.e. methods are just sorted by their name)

Personally I prefer to group methods by their functionality, so I do not need to jump too far if I trace the flow. With modern IDE's which do the jump for you this is not a big issue any more though.

In your specific example, you might want to reduce the number of methods to improve readability. If your methods are all very short (2-3 lines) and only get called from one place, you could inline the code and omit some methods.


I have found this to be more true of methods than of classes - but I think it's because I'm just not doing it enough: keep it short enough, and questions like these disappear.

So, for methods - there have long been questions about whether to initialize all the variables at the top, or to initialize them near where they're used (the answer is near where they're used, fwiw) - but if you keep your methods short enough, it just doesn't matter. Near where they're used is at the top.

Same goes, at least in theory, for classes: keep them short enough, and the internal organization just doesn't matter (limiting and impossible case: just one method per class; it's automatically in whatever order you declare). If your classes have so many methods that you're wondering how to organize - think about extracting some methods that belong together into their own class. Smaller is better.

There's doesn't seem to me to be a definitive answer to this, unless you have a standard to follow for your project/workplace. Personally, if I'm not following another standard, I put the constructor(s) first, followed by the destructor(s). After that, I just put them in alphabetical order by method name. I'm a bit of a dinosaur (I've been programming since the Carter administration), so I adopted the alphabetical approach for functions before I ever heard of object-oriented programming and just carried it over when I started doing objects.

I always order my methods like this :

first constructor/destructor, then accessors, then the other methods sorted by importance.

Important methods first, so when I open a file I have to scroll the least to get to the most important methods.

Same for public/protected/private : public first, so everything that can be used from other files is quickly visible when opening the file.

I've had this problem too. I did try to group methods based on the role of the class. That approach doesn't really work because it's leaves a lot of things unaddressed. I've recently started using the following conventions for Objective-C:

Methods are in order of decreasing audience size with the exception of initialize, init, dealloc, awakeFromNib and convenience methods (ie class methods that return an auto-released instance of the class).

//initialze, init, dealloc, awakeFromNib
//convenience methods
//General public methods
//Delegate methods (eg NSResponder, NSTableview etc)
//Binding and notification call back methods
//private methods

I'm still not 100% sure how to order ivars in the header file. For the time being I'm ordering them by memory management responsibility:

//other non-retained objects (eg delegates - these can most likely be labeled IBOutlet too)
//primative data types (no mm responsibilties)
//retained objects
Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top