Ответ 1

Нет правильного ответа на этот вопрос. Это зависит от вкуса. Я уменьшаю удобочитаемость. Не стесняйтесь давать длинное имя для своего идентификатора segue; дают длинные и выразительные имена, потому что Objective-C - очень многословный язык, позволяющий нам писать очень читаемый код.

Я обыскал официальную конвенцию, но я не смог ее найти. Вот что Apple должна сказать:

Вы назначаете идентификаторы своим сегментам в Interface Builder. Идентификатор - это строка, которую ваше приложение использует, чтобы различать один переходить из другого. Например, если у вас есть контроллер представления источника которые могут переходить к двум или более различным контроллерам представлений, вы должны назначать разные идентификаторы для каждого сеанса, чтобы Контроллеры исходного вида prepareForSegue: отправитель: метод может сказать их разделить и подготовить каждый из них соответствующим образом.

Еще одна цитата из сайта Рэй Вендерлиха:

Дайте segue уникальный идентификатор. (Он должен быть уникальным в исходная сцена; разные сцены могут использовать один и тот же идентификатор.)

Интересный подход для выбора имени идентификатора (см. выше ссылку для большего):

• Сначала напишите код, который проверяет имя идентификатора segue, прежде чем вы даже укажете имя в построителе интерфейса. Я говорю об этом коде: if ([segue.identifier isEqualToString:@"SegueIdentifierName"])

• Построить и запустить! Не заполняйте имя идентификатора в построителе интерфейса еще. Вы делаете это, потому что у вас может быть несколько исходящих segues с одного контроллера вида, и вам нужно будет различать их. Если при запуске и запуске сеанса, когда вы работаете, ничего не происходит, то ваш идентификатор имени segue уникален и хорош для использования. Если вместо этого код выполняет сеанс, который вы еще не намеревались, у вас есть конфликт для идентификатора названия скелета.

• Исправить конфликт - если есть.

• Заполните идентификатор segue в построителе интерфейса и проверьте, что он делает то, что вы хотите.

Мне нравится это, потому что он похож на TDD-подход: напишите неудачный тест, напишите какой-то код, чтобы передать неудачный тест, рефакторинг, повторить.

Ответ 2

Как и в большинстве случаев программирования, вы можете использовать любое имя, которое вам нравится.

Но, как и в большинстве случаев в программировании, имена имеют значение и Хорошие имена жесткие.

Вот как я называю segues...

Хорошие имена по умолчанию

Назовите segues, как вы бы назвали методы действий. Назовите segues тем, что они будут делать. Хорошие примеры имен segue:

• addUser
• showReport
• editAccount
• composeMessage
• reviewChanges

Названия Bad segue

Избегайте имен segue, которые просто описывают, что такое отчужденная вещь или как она работает.

Некоторые примеры имен bad segue!!:

• segueUserDetailViewController
• segueImageViewController
• RecipeViewControllerToIngredientViewController

Почему эти имена плохие?

Эти имена плохо, потому что они явно заявляют о своей реализации. Вместо того, чтобы называть то, что они делают, они называют, как они это делают. Это форма сцепления.

Правило именования для всех ваших программ

Плохо для любого имени (необязательно) указать, как что-то делается, потому что тогда вызывающий абонент определяет, как должен работать вызываемый. Эта связь будет:

• Обременяйте вызывающего абонента знаниями, которые ему не нужны.
• Произвольно ограничить реализацию вызываемого абонента ненужным способом.
• Соедините вызывающего абонента с вызываемым лицом совершенно бессмысленным и дорогостоящим способом, который необходимо сохранить или удалить в будущем.

Если кто-то впоследствии игнорирует связь и меняет реализацию, то данное имя начинает лежать и вводит в заблуждение будущего программиста, который смотрит на код, если только имя не изменено.

Следуйте за Cocoa условным обозначением

Оба Swift и Objective C используют camelCase для идентификаторов. Имена не используются _ или -. За исключением типов, классов и протоколов, все имена должны иметь строчную букву в нижнем регистре.

Вы должны назвать свои segues в camelCase строчной буквой в нижнем регистре.

Не требуется уникальность

Названия Segue не должны быть уникальными в раскадровке. Имена должны быть уникальными только в определенной сцене (контроллер просмотра).

Ответ Ilea упоминает это, цитируя сайт Рэй:

Он должен быть уникальным в исходной сцене; разные сцены могут использовать один и тот же идентификатор.

... на самом деле, часто бывает много смысла иметь одно и то же имя сегмента во многих сценах раскадровки, потому что вы могли бы addLocation из нескольких сцен.

Дополнительные советы по наименованию и работе с Segues...

Сцены могут иметь > 1 segue, идущие в ту же самую другую сцену

Это то, что я использую немного. У вас может быть контроллер вида, который может отображать и редактировать информацию об учетной записи: AccountVC. Ничто не останавливает вас, имея два или более эпизодов из сцены, которые идут на эту же другую сцену контроллера: editAccount и showAccount. Затем ваш prepareForSegue:sender: может использовать идентификатор segue для настройки AccountVC, подходящего для редактирования или просто отображения.

Используйте sender

Поскольку segues вызываются с отправителем, они очень похожи на сообщения о действиях.

Используйте segue sender для настройки контроллера представления назначения в вашей реализации prepareForSegue:sender:. Это экономит загрязнение вашего контроллера представлений с переходным состоянием для этого.

Вот пример делегата таблицы, обрабатывающего крана:

- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath
{
  Account *const account = [self accountAtIndexPath: indexPath];
  [self performSegueWithIdentifier: showAccount sender: account];
}

Что позволяет ваш метод prepare… выглядеть следующим образом:

- (void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender
{
  if([showAccount isEqualToString: segue.identifier])
  {
    AccountViewController *accountVC = segue.destinationViewController;
    accountVC.account = sender;
  }
}

Избегайте @"stringLiterals" в performSegue: вызовах

Если вы спрашиваете: "Что это за showAccount? Вы имеете в виду @"showAccount", правильно?". Большой совет: Используйте переменные области видимости файла для ваших имен переходов. Не используйте @"string literals". Итак, в верхней части моих диспетчеров вида часто есть такой блок:

DEFINE_KEY(showReport);
DEFINE_KEY(showPDF);
DEFINE_KEY(shareReport);

Макрос DEFINE_KEY находится в моем проекте .pch и выглядит следующим образом:

#define DEFINE_KEY(keyName) static NSString *const keyName = @#keyName

... он создает переменную const NSString*, значение которой равно ее имени. static означает, что он доступен только в этом "компиляционном блоке" и не загрязняет глобальное пространство имен во время соединения.

Если вы используете такую ​​переменную, у вас есть компилятор на вашей стороне. Вы не можете получить неправильное имя, потому что тогда оно не будет создано. Окончание кода поможет вам закончить начатое имя. Вы можете реорганизовать имя так же, как и любую другую переменную. Даже синтаксический маркер на вашей стороне!

Подумайте о том, как разматывать segues как исключение

Подумайте о контроллере представления назначения как обработчике исключений для разматывания segue. Развертка segue распространяет навигационный стек так же, как исключение распространяется на стек вызовов. Segue ищет обработчик раскручивания, так как исключение ищет обработчик исключений (блок catch). Он ищет обработчик для разматывания, который подходит для типа разматывания segue - опять же, это похоже на обработчик исключений для поиска типа исключений.

Важно отметить, что у вас может быть множество контроллеров представлений, реализующих один и тот же обработчик раскрутки. Разматывание будет пузыриться как исключение из первого контроллера представления, который обрабатывает его.

Обычный совет для размотки имен - это что-то вроде unwindToMessageList. Это может иметь смысл, но, следуя метафоре "обработчик исключений", может быть очень полезно для обработчиков разворота имени по тому, что они обрабатывают. Таким образом, unwindFromEventDetails, unwindFromReport или unwindFromCloseupImage могут быть хорошими именами, описывающими, что происходит. Эти обработчики могут быть реализованы на нескольких возможных сайтах catch. Соответствующий обработчик будет автоматически выбран с использованием иерархии навигации.

Ответ 3

"ViewControllerAToViewControllerB"

Например, если у вас есть MasterViewController и DetailViewController, идентификатор segue может быть:

"MasterToDetail"

Ответ 4

Лично я бы не использовал тип анимации спереди, если вы изменили анимацию, вам нужно будет вернуться к коду. Однако, если вы объявляете идентификатор segue как константу в исходном контроллере, вы можете более легко изменить имя на более позднем этапе, не копая код.

Я обычно использую имя, которое я дал контроллеру, без "ViewController". Таким образом, RatingViewController будет "Рейтинг" в качестве раскадровки. Единственное исключение - разматывание, я называю те, которые начинаются с "returnTo", заканчивающегося именем адресата ( "returnToRating" ).