Messaging in Objective-C
Objective-C is a messaging environment, not a calling environment. Although the end result is very much the same as in a calling environment, you send a message to an object in Objective-C. That message consists of an object name and a method of that object that can respond to the message. Here is an example:
[myGraphicsObject draw];
In a language such as C++, you would call a method of the object, as in:
myGraphicsObject.draw();
The arguments sent to a function (or method) in C are placed in parentheses, and their sequence is determined by the code. In Objective-C, the arguments are named. Thus, a C-style function looks like this:
resizeRect (float height, float width){ return height * width; }
If that function were part of an object in C++, you would invoke it with the following:
myRect.resizeRect (myHeight, myWidth);
An Objective-C-style function looks like this:
-(void) resizeRect: (float*) height newWidth:(float*)width { }
You invoke it with the following:
[myRect resizeRect: myHeight newWidth: myWidth];
The most important difference you notice is that the parameters in Objective-C are labeled, whereas the parameters in C or C++ are strictly positional. Do not be misled: The labels do not imply that the order of the parameters can vary. The following Objective-C function is not identical to the previous one because the labels (that is, the order of the parameters) are different:
-(void) resizeRect: (float*)width newHeight:(float*)height {
Despite the fact that there are many similarities, you will find it easier to learn Objective-C if you avoid translating back and forth to and from other programming languages you know. The principle is just the same as it is for learning a natural language—start thinking in the new language right away.
Naming Conventions
The definitive reference about naming items in your code is in "Coding Guidelines for Cocoa" located at http://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/CodingGuidelines/CodingGuidelines.html. These are detailed guidelines to help you make your code consistent with best practices and standards.
There is one guideline that is sometimes an issue. As noted previously in this hour, you can begin an instance variable name with an underscore to indicate that it is private. In some documentation, developers are advised that only Apple is to use this naming convention. That is all well and good, but some of the Xcode templates and example code do use underscores at the beginning of names for private variables. As you expand and modify your projects built on these templates and examples, you may choose to make your code consistent so that the naming convention is the same for the variables named by Apple in the template and those named by you that are syntactically parallel. Just be aware of the issue, and make your choice.
The other naming conventions are normally adopted by most developers. When there are deviations, it often is the case that a developer is not aware of the conventions.