When naming methods, we want them to read like grammatical English phrases.

These methods' base names, along with the first argument label, can form one of

three things, a prepositional phrase, a grammatical phrase, or neither.

With a prepositional phrase, the argument label, or

just the first argument, should begin at the preposition.

Creating a method that looks like this.

An exception arises when more than the first argument

represents part of the abstraction that governs the function.

Here, we have a function that fades a views background color to a new color.

The background color is determined by passing in RGB values.

Since red, green, and

blue are all part of the same abstraction split across different arguments, having

the propositional label prepended to the first argument label, doesn't read well.

So in this case, we move the proposition to the base name, and

begin the argument label after the proposition to keep the abstraction clear.

Our function therefore, reads like this.

Next up,

a method name along with the first argument can form a grammatical phrase.

It's important to note here that we're only considering the first

argument when deciding if the phase is grammatical.

We'll get into that in just a second.

With a grammatical phrase we omit the first argument label entirely and

append any preceding words to the base name.

Finally, if the methods base name and

first argument label do not form a propositional phrase and

can't be written in such a way that it is grammatically correct,

then we include a default argument label something like this.

Note that I've been focusing on the first argument label this entire time.

And that's because regardless of what type of phrase it forms.

We always label any arguments after the first one.

Also, we're only ever considering the first argument to determine

whether we have a grammatical phrase because it's okay for

fluency to degrade after the first argument or

two when those arguments are not central to the cause meaning.

There are some considerations we have to make along with these,

however, because remember we have three main guidelines we established.

Omit needless words.

Include on the words to remove ambiguity and compensate for weak type information.

Take the example of the addSubview method.

The function signature looks like this.

The method forms a grammatical phrase with the first argument label.

So we've omitted the label and appended the label to the base name.

Let's look at another example from the iOS SDK.

Here, we have a method, a type method on the NS layout constraint class

that activates an array of constraints.

The method reads activate constraints which is a grammatical phrase.

However, you'll notice here that while the argument label has been omitted

much like we did with add some view,

the word constraints is not added to the methods base name.

Why?

This is because of the guideline to omit needless words.

The argument has a type of an array of NSLayoutConstraint

which is a very specific type.

We don't typically subclass constraints to make our own.

So it's evident from our own signature that we're adding an array of constraints.

We don't need to label constraints here because it is redundant, and

we can rely on the type information.

There is one final edge case left.

After this, I'll stop, I promise.

What happens if we have a function where the arguments can't be

usefully distinguished?

Here, we have a function max that returns the maximum

of two values that we provide as arguments.

There's really no meaningful way to label these arguments in a max function

beyond value one in value two.

In such cases, we just omit all labels altogether.

It sounds like this goes against everything we've stated so far but

in practice if you choose your function based names well

it's quite obvious what's going on.

Now, I'll stress here that you don't have to adhere to all these rules on day one.

In fact, take it one at a time until these come to you naturally