Strongly Typed Identifiers
Tags: ios, swift, programming
Published: 2018-04-03 00:29:30

---
title: Strongly Typed Identifiers
published: true
description: 
tags: iOS, Swift, Programming
cover_image: https://media.giphy.com/media/3ohhwkdGpbEs7f4xiM/giphy.gif
---

**_This post originally appeared on my blog [mrtnrst](www.medium.com/mrtnrst)_**

Have you ever typed a word so many times it looks misspelled? As someone who types for a living, I tend to have trouble with this. The beauty of a misspelled word in programming is consistency. If it’s wrong everywhere, it’s right- right? However, loosely typed identifiers can lead to problems down the road for both our future selves and other code maintainers.

![](https://cdn-images-1.medium.com/max/1600/1*xnUUIJSPNh1sgIR4SbJZDg.gif)

## Starting with Colors
With most UI/UX programs, we tend to work with color, generally stemming from a style guide. Let us consider this function:

{% gist https://gist.github.com/mrtnrst/0783035ce2447057deedb66d476e2470 %}


This color view can be anything we want it to be but our guide says we can only use the colors given to us. Rather than having to remember an RGB value to create each time, let’s make it easier on ourselves.
With a small bit of setup, we can fix something that is prone to errors. We can utilize structs to achieve this.

{% gist https://gist.github.com/mrtnrst/6a1f063bbc4f95139a78b8a081f2970f %}

This is one of the simple use cases of a strongly typed identifier. The goal of this is to make sure we keep avoidable errors to a minimum.

---

## Graduating to Strings
Another pain point and source of frustration is when strings are used all willy-nilly. For instance, this function here:

{% gist https://gist.github.com/mrtnrst/c3480f9ddfe2a4cb7d98132f914c15b3 %}

A few things could happen when using this function. To name a few: misspelling of the id parameter, finding a different object with the same id or causing a crash when inside the function.

![](https://cdn-images-1.medium.com/max/1200/1*HzyTMffW_7lCyKmbGWG_cQ.gif)

So let us take a second and strongly type these functions. We want to create a struct so we can be explicit and readability is at the highest.

{% gist https://gist.github.com/mrtnrst/903e65f90c19efeb5554528f7276a667 %}


---

## Generics, Structs, and Strongly Typed Identifiers
More wisdom from Edna.Even with the extra struct, both uses still pass the compiler. Do you know why our function still accepts these values? As with all types, a String is a String no matter the alias. How about we change the type alias into something that is unique to that struct?

![](https://cdn-images-1.medium.com/max/1200/1*hIaLC8ON7Ch5OnBWPAsMuw.gif)

This is when we implement the protocols `RawRepresentable` and `Equatable` and sprinkle in Generics to create this:

{% gist https://gist.github.com/mrtnrst/21be873d948168f9cf7dec1abef7883e %}


As for the usage of this new and improved function:

{% gist https://gist.github.com/mrtnrst/790383a08ac44ff6d8c41448c9c78489 %}

---

## Voila!
We have now locked up our function and kept the errors at bay. There are many different ways you can keep function associations close and organized. My advice to you is to start with low hanging fruit and keep building.

![](https://cdn-images-1.medium.com/max/1600/1*Nb48ETsZv8ZliOuV7TX67w.gif)