Почему в Swift используется camelCase, а на бэке snake_case

Что проверяют

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

Как отвечать

Это конвенции, а не техническое ограничение. В Swift действует свой гайдлайн: lowerCamelCase для свойств и методов, UpperCamelCase для типов. На бэкенде snake_case пришёл из традиций языка и из базы, где колонки пишут через подчёркивание, а JSON наследует их имена напрямую.

Спорить, чей стиль правильнее, бессмысленно: клиентов у API несколько, формат ради одного никто не поменяет. Значит, задача сводится к сопоставлению имён, и место у него одно, слой моделей передачи данных.

struct Profile: Decodable {
  let firstName: String
  let avatarURL: URL?

  enum CodingKeys: String, CodingKey {
    case firstName = "first_name"
    case avatarURL = "avatar_url"
  }
}

Для ровного API есть короткий путь: decoder.keyDecodingStrategy = .convertFromSnakeCase. Называть его стоит вместе с оговоркой: стратегия применяется ко всем ключам сразу и не всегда угадывает аббревиатуры и числа, поэтому исключения всё равно закрываются через CodingKeys.

Хороший финал: формат сети это деталь транспорта, доменная модель приложения про неё знать не должна.

Где спотыкаются

Объявляют свойства в snake_case, лишь бы не писать CodingKeys. Код перестаёт проходить ревью и линтер, а на первом же ключе с дефисом или с цифрой явное соответствие всё равно понадобится.

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

Третье: отвечают про вкусы и читаемость, хотя вопрос про интеграцию. Ждут слов про Codable, единственное место сопоставления имён и про то, что модель экрана не обязана повторять структуру ответа.