Swift: How To Name Your Extensions

Posted on July 26th, 2015

One of my favorite patterns in iOS programming with Swift is to create multiple extensions throughout my files to keep related methods together. For example, every time my ViewController conforms to a protocol, I keep the protocol methods together in an extension. Same goes for multiple private styling methods or private cell configuration methods in a table view, etc.

The only thing missing from this pattern was that I was unable to name the extensions. Instead, I had to use // MARK: everywhere to keep track of the groupings. I mentioned this to @allonsykraken the other day, and he showed me a simple trick for this – using typealias!

import UIKit

class ViewController: UIViewController {

    @IBOutlet weak var tableView: UITableView!
    
    override func viewDidLoad() {
        super.viewDidLoad()
        
        styleNavigationBar()
    }
}

private typealias TableViewDataSource = ViewController
extension TableViewDataSource: UITableViewDataSource {
    
    func tableView(tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
        return 5
    }
    
    func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell {
        let cell = tableView.dequeueReusableCellWithIdentifier("identifier", forIndexPath: indexPath)
        return cell
    }
}

private typealias TableViewDelegate = ViewController
extension TableViewDelegate: UITableViewDelegate {
    
    func tableView(tableView: UITableView, heightForRowAtIndexPath indexPath: NSIndexPath) -> CGFloat {
        return 64.0
    }
}

private typealias ViewStylingHelpers = ViewController
private extension ViewStylingHelpers {
    
    func styleNavigationBar() {
        // style navigation bar here
    }
}

import UIKit

class ViewController: UIViewController {

@IBOutlet weak var tableView: UITableView!

override func viewDidLoad() {

super.viewDidLoad()

styleNavigationBar()

}

private typealias TableViewDataSource = ViewController

extension TableViewDataSource: UITableViewDataSource {

func tableView(tableView: UITableView, numberOfRowsInSection section: Int) -> Int {

return 5

}

func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell {

let cell = tableView.dequeueReusableCellWithIdentifier("identifier", forIndexPath: indexPath)

return cell

}

private typealias TableViewDelegate = ViewController

extension TableViewDelegate: UITableViewDelegate {

func tableView(tableView: UITableView, heightForRowAtIndexPath indexPath: NSIndexPath) -> CGFloat {

return 64.0

}

private typealias ViewStylingHelpers = ViewController

private extension ViewStylingHelpers {

func styleNavigationBar() {

// style navigation bar here

}

I’m sure you’re now wondering the first thought that popped into my head when I saw this – what about the groupings in the Xcode nav bar?!!! Don’t worry, it’s all there!

Extensions Swift

Let me know what you think about naming your extensions like this in the comments! Would love feedback as I’m still deciding how much I like this vs just using MARK: here.

Enjoy the article? Join over 17,500+ Swift developers and enthusiasts who get my weekly updates.

Tomasz Szulc

IMO this is weak. When you create another view controller and try the same trick you end up with “Invalid redeclaraion of ‘TableViewDataSource’. I think you probably assumed there will be just this one data source in the app or in this example and this is not the case now.
- Natasha Murashev
  
  I tried it in a diff view controller with the same typealiases and it works. That’s why I made the typealiases private.
- Natasha Murashev
  
  Either way, you could name them to be more specific: MyViewControllerDataSource. Focusing on the concept here.
Matteo Manferdini

I personally would not do this. My style is to not write code that is not necessary. It seems to me (correct me if I’m wrong) that you are doing this to get Xcode to list the names of the extensions in the navigation bar. That’s what // MARK: is for, and this is clear to everyone reading your code.

Declaring a private typealias is an obscure way to obtain the same, but that’s not what type aliases are for. Anyone else reading your code would wonder: what is this for? They are not required for extensions and since these type aliases are never used anywhere, the reader would not find an answer to this question.

It would be great if Xcode displayed them without any additional line. But since it doesn’t, my preference goes to // MARK:
- Tomasz Szulc
  
  +1
- Isuru Nanayakkara
  
  I agree. Sprinkled typealiases seem messy.
- zjczhjuncai
  
  I agree.
  private typealias causes more confusion. The more you write, the more chance to get wrong.
- Yariv
  
  “// MARK: – ” will show a line, drop the “-” to not have a separator line
- Rainer Drexler
  
  Full Acknowledge. Nobody should do that. For me it´s a anti pattern
Vjosullivan

Works less well on extensions like Equatable or Comparable where the == and < functions are defined after rather than inside the extension declaration. When that happens the functions aren't indented in the drop-down, so the hierarchy is less visible. (However, as stand-alone functions they are prefixed with an "f" icon rather than an "m" icon, as above.
sketchyTech

Really interesting idea, thanks for sharing Natasha. What I’ve found myself doing is having a folder (or group) named ViewController, for example, then within that folder having the main class (or type), then for each extension or range of extensions have additional files named _TableViewDataSource.swift, _TableViewDelegate.swift and so on. I hate having code files that are overly long and being able to collapse and expand groups makes for easy navigation. I can then use // MARK: within the files for even quicker navigation to the subparts.
- Natasha Murashev
  
  Interesting idea as well. I wouldn’t like having that many files personally and I try to keep my ViewControllers short, so it hasn’t been too much of a problem.
  - sketchyTech
    
    Writing a JSON parser is where I first did this because I had a central enum type with Array, Dictionary, String, etc. and I wanted to separate the functionality of each while being able to have a single type.
- Piotr Tobolski
  
  Creating separate files for those categories would disallow usage of private properties, methods nad functions in categories
  - sketchyTech
    
    Yes, you would be restricted here but for the type of separation I’m thinking of this might well be an advantage. The issue has mainly arisen for me so far, as noted below, where I need a whole variety of functionality in a single type that is internally segregated. This need might change in future if the sophistication of the “where” keyword expands.
Kevin Xu

I still like my // MARK: – UITableViewDataSource above the extension. The different code style / color helps me easily scan the different sections
- Natasha Murashev
  
  I’ll probably still keep the //MARK: as well, but found this to be an interesting idea to explore.
  - Kevin Xu
    
    Ditto, love exploring new ideas! One of the handiest usages for typealias for me so far has been aliasing complex completion blocks like typealias SuccessCompletionBlock = (RKObjectRequestOperation!, RKMappingResult!) -> Void
    - Natasha Murashev
      
      +1 to that! I do that all the time.
    - vanylapep
      
      I always find a problem with this tho. Since you are not giving a parameter name, it’s hard for the person who reads your code know what RKObjectRequestOperation and RKMappingResult are for. In your example, it could be self explanatory, but when you have Bool, it’s hard to guess what it represent. Or am I not understanding this correctly?
      - Kevin Xu
        
        That’s true, ideally one can cmd+click the alias into it’s actual definition that maybe supplies a comment explaining things
      - vanylapep
        
        That could work.
Huan

I prefer // MARK: style , typealias looks interesting , but as chinese words goes, “然并卵！”
Bob Godwin

Natasha I really love your posts but this last one is not convincing.. [typealias] like the word implies should be used to expose a generic type for public use and not for [//MARK: – ] We are still looking for the correct design patterns for swift and I believe you can do better..:) However typealias is very interesting and I believe every one should read some thing about it. For example I was able to use it expose an NSManagedObject attributes… Please keep writing…
- Rainer D.
  
  Full Acknowledge
Chlebta kaouach

Please someone explain the advantage of using extension ? why using them ?
- Edias
  
  On this specific case I can’t see any…
- Tony Dunkin Hung
  
  I think it keeps the file clean and makes the extension more readable. Like if you have a extension on a viewController with similar functions, it would be nice to put a name to it. If other developer comes onto the project, they won’t have to read all the functions in that extension to understand what it does, you can just read the name of the extension
Edias

Hi Natasha,

Sorry for the question but I’m just curious…

Which benefits you see breaking down your TableViewDelegate and TableViewDataSource in separated extensions?
Stanislav

Here I wrote about why I won’t do it. https://medium.com/@stanislavsmida/dont-use-extensions-primary-for-structuring-your-code-7b3af9baae17