Здесь должна быть шутка о том, что самое сложное в программировании - это придумывать названия переменным.
Здравствуйте, коллеги.
С новой командой разрабатываем проект. Предполагается web-интерфейс в виде spa на vue и публичный api. Формат Обмена данными между сервером и клиентом - json.
И возникла дискуссия о том, какой регистр использовать для ключей объекта json - camelCase или snake_case.
Везде, где я работал, мы в основном использовали snake_case, но больше по историческим причинам.
Было предложение остановиться на camelCase. В js преимущественно используется этот регистр для именования сущностей. Но коллега возразил, что для публичного api лучше использовать snake_case - более распостранённый подход, будет более привычно для пользователей api.
В целом, мы на spa и api отдаём немного разные наборы данных, так что технически ничто не мешает использовать camelCase для spa и snake_case для api. Но лично мне хотелось бы придерживаться единого подхода.
И тут возникает ещё одна проблема. Я уже написал, что spa и api получают немного разные наборы данных, но вот получаем мы данные с api и spa одинаковые. И вот тут уже разделение никак не получится, поскольку для валидации и прочего нужно будет писать разные классы. Либо городить какие-нибудь мапперы, что в данном случае будет явно лишним.
Было ещё предложение возвращать объекты с ключами в camelCase, а получать - в snake_case. Но на мой взгляд, это предложение совсем уж никуда не годиться. На мой взгляд, разный регистр для входящих и исходящих данных не имеет смысла.
Я понимаю, что данный вопрос не имеет однозначного ответа и не может быть правильного и неправильного подхода.
Хочется в основном собрать мнения, статистику.
Какой подход преимущественно используете вы и почему?
XG22, нет никакого смысла городить два разных подхода. Тем более что наверняка некоторые API-вызовы будут использоваться и в публичном API, и в SPA. Отсылки на распространённость практики не заградительны: вы можете делать так, как вам удобнее. Особенно если публичный API у вас будет глубоко вторичным способом работы.
Но это в любом случае решать вам внутри команды, а не посторонние пользователи Хабра будут за вас решать. Если с консенсусом в команде сложно - пусть окончательнео решение принимает тимлид.
shurshur, о том и речь - нужно выбрать единый подход. Использовать разные подходы никто не собирается.
Вероятно, я плохо сформулировал вопрос. Ну, если это можно назвать вопросом.
Просто абсолютное большинство команды за camelCase. В первую очередь из соображений унификации именования в js-коде. А публичный api мы отдаём на сторону. Что даём, тем и пользуйтесь.
Вообще, насчёт вторичности api - вопрос сложный. Предполагается, что нет. Но там, конечно, как пойдёт.
Но один коллега упёрся рогом, что использование snake_case является правилом хорошего тона, а camelCase - плохо. Но никаких пруфов, где я смог бы прочитать, что вот так - хорошо, а так - плохо, он так и не предоставил.
На самом деле, вопрос уже решён. Мы остановились на camelCase.
Тут я задал вопрос исключительно с целью - разобраться для себя. Вдруг действительно существуют какие-нибудь рекомендации, негласные правила и так далее. Просто я особо никогда даже не задумывался об этом. Всегда использовали то, что удобнее. Ну и анализ публичных api разных сервисов показывает, что единого подхода нет. Да, snake_case встречается чаще, но не сказал бы что camelCase - такая уж редкость.
Но один коллега упёрся рогом, что использование snake_case является правилом хорошего тона, а camelCase - плохо. Но никаких пруфов, где я смог бы прочитать, что вот так - хорошо, а так - плохо, он так и не предоставил.
Доказывать должен утверждающий, иначе ситуация как у вас, кто-то что-то сказал не аргументируя, а вы теперь землю роете, дабы доказать. Тут уже не вопрос cases, а вопрос, что у вас за "звезда" в команде, что вокруг нее нужно бегать.
"анализ публичных api разных сервисов показывает, что единого подхода нет" - именно так. Да и проблема именования имен несколько об ином, а здесь и не проблема вовсе.
И, главное, используйте хоть оба варианта, там не нужно никаких мапперов, один case в другой конвертируется 2-3 строчками кода.
