[MUSIC]

Objective-C has been around for quite a while, and

during that time lots of conventions have come into being.

Some are simply styles for naming methods or variables.

Others are more conceptual and

represent idiomatic ways of handling common problems.

Let's poke around a bit and answer a few of the whys that might be floating

around in your head as you explore Objective-C code bases.

So in this video we'll focus on naming conventions.

In terms of idiomatic ways of handling problems, we'll get a sampling of that as

we explore design patterns and some complete Objective-C apps.

Most of the naming conventions I'll describe are simply accepted best practice

in terms of style, while other naming conventions must be followed in order for

things to work correctly.

I'll point out the latter when it applies,

as that could really come back to bite you.

Let's begin with class names.

There are a few basic rules to follow here.

Apple framework classes used to letter prefixes like NSArray,

CALayer, or UILabel.

We've talked about what NS stands for,

but the CA and UI are more relevant to your everyday life.

They signal that the class belongs to the Core Animation framework and

the UI Kit framework, respectively.

Alternatively, when you create your own classes in your projects,

you should generally use a three letter prefix that makes sense for

your project and organization.

Since the apps we've built in this course are really tiny,

I just called classes animal or canine.

But in a real world app, something like TRHAnimal for

tree house animal would be clearer.

Classes use CamelCase.

Instances of classes use lower camelCase.

Classes should always be named after what they are or do in terms of your app.

For instance, ABCLoginViewController or XYZPdfMaker.

Lastly, class names should be unique across your app.

As for method names, in general they should be expressive and descriptive.

The names shouldn't just make sense, but they should convey useful meaning and

context to anyone reading your code.

Avoid abbreviations unless they're commonly used, and

I've linked a list of those below.

Method names should be lower camelCase.

That's different than many languages like C# that use upper CamelCase.

The method names you choose only need to be unique within a class,

though remember that if you use that name again in a subclass, it will override

the superclass's implementation when you call it on the subclass.

Be sure to name your parameters descriptively but concisely.

Otherwise they can quickly get out of control.

And if you're passing an error as a parameter, list that last.

There are also a few required conventions for methods we should point out.

For accessors, if you want to set a property called userEmail,

you should name that method setUserEmail.

The getter is simply the property name.

However, if the property you're setting and getting is a boolean, like LoggedIn,

you should use the set prefix for the setter and the is prefix for the getter.

These conventions are critical if you wanna make use of key value coding and

key value observing, which are both really powerful.

And yes, I've linked to some resources on those below as well.

Lastly, if you wanna create a factory method, let's say for

the Animal class, you use a lower camelCase of the class name like so.