I'm finishing up a port I did of a portion of a Java Library. The library calculates sunrise and sunset for a given latitude and longitude. The original Java library also calculated various times based on sunrise and sunset, which I plan to get to later.

That said, I'm working with Objective-C and the Cocoa touch framework. The original methods, being Java, all began with get and took their arguments in parenthesis. However, Objective-C has a different method structure, so the methods end up looking different. For example,

public double getUTCSunset(AstronomicalCalendar astronomicalCalendar, double zenith, boolean adjustForElevation)

becomes this:

- (double) getUTCSunsetForDate:(NSDate*)date andZenith:(double)zenith adjustForElevation:(BOOL)adjustForElevation.

The problem here is twofold. First of all, according to the Apple Documentation on coding convention, method names (and "getters"), should not include get in them. However, a second issue arises if we drop the get. We end up with a method signature that begins with a capital letter, which is also not supposed to happen.

How would you rewrite this method, while keeping the method signatures similar enough to be recognizable to each other?

2 Answers 2


- (double) UTCSunsetForDate:(NSDate*)date andZenith:(double)zenith adjustForElevation:(BOOL)adjustForElevation

I think you can start with a capital letter if it's an acronym. Look at NSURLRequest class where some methods begin with URL or HTTP.

Actually, here's a quote from Apple coding guidelines

Start the name with a lowercase letter and capitalize the first letter of
embedded words. Don’t use prefixes. See “Typographic Conventions.” There are two specific exceptions to these guidelines. You may begin a method name with a well-known acronym in uppercase (such as TIFF or PDF)), and you may use prefixes to group and identify private methods (see “Private Methods”).


I haven't really been writing a lot of Objective C these days, but I would expect a method signature like this:

- (double) utcSunsetForDate:(NSDate*)date andZenith:(double)zenith adjustingForElevation:(BOOL)adjustForElevation

'utc' doesn't look as great, but it's definitely better than 'uTC', 'getUTC' or even 'universalCoordinatedTime', which is just way too verbose.

Also, should the return valu really be a double, rather than a UTCTime or something similar?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.