Storyboard Segue Identifier naming conventions

Question

I\'m building a large storyboard and I was wondering if anyone has come up with helpful naming conventions for segue identifiers.

It looks like Apple j

Answer 1

There is no correct answer for this question. It depends on taste. I mitigate for readability. Don't be shy to give a long name for your segue identifier; give long and expressive names because Objective-C is a very verbose language leveraging us to write very readable code.

I have searched for an official convention, but I couldn't find any. Here's what Apple has to say:

You assign identifiers to your segues in Interface Builder. An identifier is a string that your application uses to distinguish one segue from another. For example, if you have a source view controller that can segue to two or more different destination view controllers, you would assign different identifiers to each segue so that the source view controller’s prepareForSegue:sender: method could tell them apart and prepare each segue appropriately.

Another quote from Ray Wenderlich's site:

Give the segue a unique Identifier. (It only has to be unique in the source scene; different scenes can use the same identifier.)

An interesting approach for picking the identifier name (see above link for more):

1. First write the code that verifies for the segue identifier name BEFORE you even set the name in the interface builder. I'm talking about this code: if ([segue.identifier isEqualToString:@"SegueIdentifierName"])

2. Build & Run! Don't fill in the identifier name in the Interface Builder yet. You do this because you may have multiple outgoing segues from one view controller and you’ll need to be able to distinguish between them. If nothing happens while you run and trigger the segue you're working on, then your segue name identifier is unique and good to be used. If instead the code performs a segue that you haven't intended, you have a conflict for the sague name identifier.

3. Fix the conflict - if any.

4. Fill in the segue identifier in the Interface Builder and test that it does what you want.

I like this because it's like a TDD approach: write a failing test, write some code to pass the failing test, refactor, repeat.