JSON 키에 하이픈을 사용하는 것은 나쁜 습관입니까?

하이픈 (kebab-case)을 사용하는 JSON 키에 액세스하는 것과 관련하여 많은 질문이 있지만 이제는 키에서 camelCase 또는 snake_case를 고수 해야하는지 궁금합니다. 하이픈은 언어간에 이식 될 때 복잡한 매핑을 만들 수도 있다는 것을 알고 있습니다. 일부 JSON deserialize 라이브러리가 해당 키를 camelCase 스타일로 변환하는 것을 보았습니다.

예:

var something = {
  "some-value": 'thing'
}

대

var something = {
  "someValue": 'thing',
  "some_other_value": 'thing_two'
}

유효한 UTF-8이고 0 코드 포인트를 포함하지 않는 한 JSON 키로 무엇이든 사용할 수 있으며 선택한 프로그래밍 언어에서 키를 문자열로 나타낼 수 있으면 유용합니다. 동일한 문자열의 다른 유니 코드 표현 (예 : 하나 또는 두 개의 코드 포인트로 작성된 "Ä")을 사용하지 않는 것이 좋습니다.

주석 읽기 : 일부 사람들은 JSON 사전의 키와 일치하는 인스턴스 변수로 클래스를 작성하려고합니다. COBOL을 작성하지 않으면 키가 "일부 값"인 경우 어떤 것이 작동하지 않습니까? 나는 이것이 잘못 인도되었다고 생각합니다. 나는 길 설계 모델 클래스가 내가 그들을하고자합니다. JSON은 방금 모델 클래스를 채우는 데 사용됩니다. 나는 서버 남자가 키의 사용에 넣어하기로 결정대로 할게요 내 모델 객체.

통합 된 언어로 사용하기에 적합하지 않은 필드 이름 간의 매핑을 처리 할 수있는 JSON 직렬화 시스템이 많이 있습니다. 대부분의 경우 사용하기 어렵지 않으며 약간의 추가 노력 만 필요합니다. 이상적인 세상에서는 꼭 할 필요는 없지만 API가 이미 대시를 사용하는 경우 변경하는 것이 질병보다 더 나빠질 수 있습니다. 또한 대시 사용은 특정 언어, 특히 LISP를 기반으로하는 언어에서 가장 일반적인 스타일이므로 다른 형식보다는 대시를보고 싶어하는 API 소비자가 소수 일 것입니다.

업계에서 시간을 보내고 몇 가지 시스템을 작업 한 후. JSON 키에 대한 모범 사례 또는 적절한 케이스가 있다고 생각하지 않습니다. 모든 형식 (케이싱 / 코드 스타일 등)의 가장 중요한 측면은 일관성과 팀 채택입니다.

코드베이스가 조각화되고 일관성이 없으면 팀으로 만나 일관된 스타일에 동의 한 다음 형식을 종합적으로 감시하십시오.