AppController.h

#import <Cocoa/Cocoa.h>


@interface AppController : NSObject {
	
	
	IBOutlet NSTextField *clockInTextField;
	IBOutlet NSTextField *clockOutTextField;
	IBOutlet NSTextField *resultsField;
	IBOutlet NSTextField *payRateField;
	IBOutlet NSTextField *totalPayField;
	
	

}


- (IBAction)calculateNumber:(id)sender;

@end

AppController.m

#import "AppController.h"


@implementation AppController

- (IBAction)calculateNumber:(id)sender
{   
  int hoursWorked = max( [clockInTextField intValue], [clockOutTextField intValue] ) - min( [clockInTextField intValue], [clockOutTextField intValue] );
  int hourlyRate = [payRateField intValue];
  
  [resultsField setStringValue:[NSString stringWithFormat:@"%d hours worked", hoursWorked]];
  [totalPayField setStringValue:[NSString stringWithFormat:@"%d dollars earned", hoursWorked * hourlyRate]];
}

@end

// Some notes: this code is untested but probably will work

// In general it would be better to enforce that the clock out hour cannot
// be earlier than the clock in hour via the UI but, even accounting for
// that, it's better to be sure (you never know where your inputs may come
// from).

// Your solution duplicates a lot of code in two pathways where the code
// that is different for those pathways is, essentially, just the first
// line. I've taken things a little further by cutting to the chase and
// using the built-in C functions min() and max() to avoid having to work
// out which is higher.

// I think it would be useful for you to reflect on why you ended up with
// the solution you did. From a very pragmatic standpoint the more code
// you write the more errors you will get. The rate may vary but it's a
// fact. It's very important therefore to identify redundant and duplicate
// code and remove it. With less code to look at you will find it easier
// to spot mistakes and easier to come up with more elegant solutions.

// Also some of your variables are very poorly named. Your outlets are good,
// but within the action the naming is very poor: "number", "numberTwo",
// "numberThree"? If this were a real app you might be surprised how quickly
// you will forget what they really mean. Then you have to comprehend and
// everything gets a lot slower and more difficult.

// Get into the habit, right away, of always naming variables to describe
// their purpose or what they represent. Exceptions are things like 'i'
// for a loop index where the loop *is short* but in almost all other cases
// your variables should be telling you what they are for.

// Also you're still using return statements where you don't need to.
//  Think about why you put returns where you did, what purpose is served
// putting them there.

// I don't wish to sound overly critical, you're making good progress.
// But now is a good time to think about how you're approaching code so
// that you can develop good habits.

// Good luck, M.