[MUSIC]

Hi My name is Pasan and welcome to API Design Guidelines in Swift.

Now that's a complicated sounding title for a simple premise.

Over the next two videos we're going to learn how to write idiomatic Swift,

that is Swift that reads well, promotes clarity and

is consistent with how the Swift community structures its code.

When Swift was first released, despite having been worked on for

several years at apple, it had no distinct style or

guidelines on what writing good Swift meant.

Moreover working with Swift meant and

still means working largely with objective C code.

Which has wildly different stylistic considerations and conventions.

This meant that, during the early days of swift especially,

everyone wrote swift kind of how they wanted to.

Some mimic the verbose style of objectives seen, others coming

from different domains and backgrounds applied their own set of styles.

There was plenty of confusion.

To add to this Swift was rapidly changing both in the language itself and

how it translated Objective-C API.

These changes came in a very short time frame,

which meant even more inconsistency across the language.

With the open sourcing of Swift in 2015, the Swift team took steps

towards creating a consistent style, and establishing a set of guidelines.

This is a great thing.

Prior to Swift 3 there wasn't any sort of consistency within the community, and

the only way to know how to name types in methods.

Was to look at the standard library for examples.

These new guidelines mean that your Swift code looks like everyone else's Swift

code, which is really important because when you read their code it looks more or

less like your code.

There are a lot of changes though,

especially if you're coming from Swift 2 rather than starting new.

And because this is the first time any sense of consistency has been applied

officially.

So rather than talk about these things in separate courses,

I thought we could take some time to bring it all together.

And go through several examples.

Before we start however, I should say that this course might seem overwhelming.

And full of rules that seem way too strict.

Don't worry about internalizing any of this, right off the bat or

memorizing the rules.

These videos are mostly meant to give you a good sense of the scope of changes,

rather than to force you to change your style immediately.

Particularly for

those of you that are new, a set of videos on naming things might seem a bit much.

Don't worry.

You'll get used to all of these rules as you write more code.

Until eventually this is all second nature.

There are two big goals driving the choices that we'll talk about

throughout these videos that are important to keep in mind.

First, the most important goal when writing Swift

is clarity at the point of use.

What is at point of use mean?

It means that when we write methods or functions, how they read when we

call those methods, is far more important than when we define them.

Methods and properties are written once, and called and used many times.

So the focus should be on the latter keep us in mind.

Second clarity is more important than brevity.

Swift was introduced as a successor more or less to Objective C.

With Objective C, we had been writing verbose or

long method names variables and properties.

They were extremely clear about their intent often redundantly.

So with the arrival of Swift the pendulum swung in the opposite direction, and

people started writing the least amount of code they possibly could.

Often taking inspiration from sources like Python with its list comprehension.

Well that works well in other languages that's not what we want in Swift.

In Swift we want to understand the code well even if that means writing more.

Again Clarity is more important than Brevity.

To quote the guidelines, it is a non goal to enable the smallest possible code.

Instead when Brevity occurs

it is as a side effect of using some of Swift's great features.

So, keep these goals in mind they're pretty important.

For the rest of these videos we're going to break it up into two main sections.

Naming types, properties, and

variables as our first section and naming methods second.

Let's start with naming types.