Bummer! This is just a preview. You need to be signed in with a Basic account to view the entire video.
Start a free Basic trial
to watch this video
In this video we talk about the why of all this. Why does everyone need to write Swift the same way to begin with?
-
0:00
[MUSIC]
-
0:04
Hi My name is Pasan and welcome to API Design Guidelines in Swift.
-
0:09
Now that's a complicated sounding title for a simple premise.
-
0:14
Over the next two videos we're going to learn how to write idiomatic Swift,
-
0:18
that is Swift that reads well, promotes clarity and
-
0:22
is consistent with how the Swift community structures its code.
-
0:27
When Swift was first released, despite having been worked on for
-
0:30
several years at apple, it had no distinct style or
-
0:34
guidelines on what writing good Swift meant.
-
0:38
Moreover working with Swift meant and
-
0:40
still means working largely with objective C code.
-
0:44
Which has wildly different stylistic considerations and conventions.
-
0:49
This meant that, during the early days of swift especially,
-
0:52
everyone wrote swift kind of how they wanted to.
-
0:55
Some mimic the verbose style of objectives seen, others coming
-
0:59
from different domains and backgrounds applied their own set of styles.
-
1:03
There was plenty of confusion.
-
1:05
To add to this Swift was rapidly changing both in the language itself and
-
1:10
how it translated Objective-C API.
-
1:13
These changes came in a very short time frame,
-
1:16
which meant even more inconsistency across the language.
-
1:20
With the open sourcing of Swift in 2015, the Swift team took steps
-
1:24
towards creating a consistent style, and establishing a set of guidelines.
-
1:29
This is a great thing.
-
1:31
Prior to Swift 3 there wasn't any sort of consistency within the community, and
-
1:35
the only way to know how to name types in methods.
-
1:38
Was to look at the standard library for examples.
-
1:42
These new guidelines mean that your Swift code looks like everyone else's Swift
-
1:46
code, which is really important because when you read their code it looks more or
-
1:50
less like your code.
-
1:52
There are a lot of changes though,
-
1:54
especially if you're coming from Swift 2 rather than starting new.
-
1:58
And because this is the first time any sense of consistency has been applied
-
2:02
officially.
-
2:03
So rather than talk about these things in separate courses,
-
2:07
I thought we could take some time to bring it all together.
-
2:09
And go through several examples.
-
2:12
Before we start however, I should say that this course might seem overwhelming.
-
2:17
And full of rules that seem way too strict.
-
2:20
Don't worry about internalizing any of this, right off the bat or
-
2:24
memorizing the rules.
-
2:26
These videos are mostly meant to give you a good sense of the scope of changes,
-
2:31
rather than to force you to change your style immediately.
-
2:35
Particularly for
-
2:36
those of you that are new, a set of videos on naming things might seem a bit much.
-
2:41
Don't worry.
-
2:42
You'll get used to all of these rules as you write more code.
-
2:45
Until eventually this is all second nature.
-
2:49
There are two big goals driving the choices that we'll talk about
-
2:52
throughout these videos that are important to keep in mind.
-
2:56
First, the most important goal when writing Swift
-
2:59
is clarity at the point of use.
-
3:03
What is at point of use mean?
-
3:05
It means that when we write methods or functions, how they read when we
-
3:10
call those methods, is far more important than when we define them.
-
3:15
Methods and properties are written once, and called and used many times.
-
3:20
So the focus should be on the latter keep us in mind.
-
3:25
Second clarity is more important than brevity.
-
3:29
Swift was introduced as a successor more or less to Objective C.
-
3:34
With Objective C, we had been writing verbose or
-
3:37
long method names variables and properties.
-
3:41
They were extremely clear about their intent often redundantly.
-
3:45
So with the arrival of Swift the pendulum swung in the opposite direction, and
-
3:50
people started writing the least amount of code they possibly could.
-
3:54
Often taking inspiration from sources like Python with its list comprehension.
-
4:00
Well that works well in other languages that's not what we want in Swift.
-
4:05
In Swift we want to understand the code well even if that means writing more.
-
4:10
Again Clarity is more important than Brevity.
-
4:14
To quote the guidelines, it is a non goal to enable the smallest possible code.
-
4:20
Instead when Brevity occurs
-
4:23
it is as a side effect of using some of Swift's great features.
-
4:28
So, keep these goals in mind they're pretty important.
-
4:31
For the rest of these videos we're going to break it up into two main sections.
-
4:35
Naming types, properties, and
-
4:37
variables as our first section and naming methods second.
-
4:41
Let's start with naming types.
You need to sign up for Treehouse in order to download course files.
Sign up