자식 리포지토리에 대한 명명 규칙이 있습니까?


328

예를 들어, 구매 서비스라는 RESTful 서비스가 있습니다. 저장소 이름을 지정해야합니까?

  1. purchaserestservice
  2. purchase-rest-service
  3. purchase_rest_service
  4. 또는 다른 것?

컨벤션은 무엇입니까? Github는 어떻습니까? 공공 저장소는 어떤 표준을 따라야합니까?


4
이 블로그 게시물 일부 사용이 될 수 gravitydept.com/blog/...
PHeiberg

답변:


379

갈 것입니다 purchase-rest-service. 원인:

  1. "체이스 체이스 휴식 서비스"란 무엇입니까? 길고 연결된 단어는 이해하기 어렵습니다. 나는 독일인입니다. "Donaudampfschifffahrtskapitänspatentausfüllungsassistentenausschreibungsstellenbewerbung."

  2. "_"는 "-"보다 입력하기가 어렵습니다.


151
나는 (정말로) 이해하지 못하지만 ... auschreibung에서 S를 그리워하지 않았습니까 ...?
Vili

6
@adimauro : 다뉴브 스팀 보트의 선장 특허 양식을 작성하기 위해 조수로 열린 위치에 대한 응용 프로그램입니다.
Aaron Digulla 2016 년

6
낙타 케이스를 좋아하지 않는 특별한 이유는 무엇입니까? 그것은 특별한 문자를 사용하지 않기 때문에 공통 항목 명명 규칙입니다.
10gistic

31
@ 10greposito repo 이름은 대소 문자를 구분하지 않거나 소문자로 변환 할 수있는 URL (예 : github)에서 종종 볼 수 있으므로 camelCase는 나쁜 생각입니다. 나는 github이 이것을하지 않는다고 생각하지만 여전히 저장하는 것이 좋습니다.
jdg

19
GitHub의 사람들은 하이픈을 사용합니다. habrastorage.org/getpro/habr/post_images/d34/331/a8d/…
airato

72

낙타의 경우 문제는 종종 단어의 다른 해석 (예 : checkinService와 checkInService)이 있다는 것입니다. 아론의 대답과 함께, 비슷한 리포지토리를 가진 사람이 당신이 관심있는 리포지토리를 만든 사람이 대문자와 소문자의 특정 분류를 사용했는지 지속적으로 확인 해야하는 경우 자동 완성이 어렵습니다. 대문자를 피하십시오.

대시에 대한 그의 요점도 잘 조언되어 있습니다.

  1. 소문자를 사용하십시오.
  2. 대시를 사용하십시오.
  3. 구체적이다. 나중에 유사한 아이디어를 구별해야 할 수도 있습니다. 즉 서비스 나 휴게 서비스 대신 구매 휴게 서비스를 사용하십시오.
  4. 일관성을 유지하십시오. 다양한 GIT 공급 업체의 사용량을 고려하십시오. 리포지토리를 어떻게 정렬 / 그룹화 하시겠습니까?

3
귀하의 답변은 가장 중요한 답변이 해결하지 못한 두 가지 중요한 문제를 다룹니다.
Will Beason

4
체크인 서비스인지 체크인 서비스인지를 잊어 버리는 것이 checkinService인지 checkInService인지를 잊어 버리는 것보다 나은가?
MarredCheese

낙타 케이스는 네이티브가 아닌 스피커에게는 더 어렵습니다.
벤 Aveling

48

lowercase-with-hyphens GitHub에서 가장 자주 볼 수있는 스타일입니다. *

lowercase_with_underscores 아마 두 번째로 가장 인기있는 스타일 일 것입니다.

전자는 키 입력을 저장하기 때문에 선호합니다.

일화; 데이터를 수집하지 않았습니다.


8
하이픈도 SEO 장점이 있습니다. 이것은 중요한 고려 사항은 아니지만 URL에 대해 이야기하고 있기 때문에 관련성이 있습니다.
Michael Scheper 2016 년

12
하이픈은 또 다른 이점이 있습니다. 밑줄이있는 하이퍼 링크에서 쉽게 찾을 수 있습니다 (밑줄은 공백으로 쉽게 착각 할 수 있음).
Jeroen

1
언급 한대로 데이터를 수집하기는 어렵지만 github.com/trending/developers를 방문하여 언급 된 이전 스타일 만 보았습니다.lowercase-with-hyphens
SaTa

21

특정 명명 선택을 선호하지 않고 git repo를 원하는 루트 디렉토리로 복제 할 수 있습니다.

git clone https://github.com/user/repo.git myDir

여기 디렉토리에 repo.git복제됩니다 myDir.

따라서 공개 리포지토리에 대한 명명 규칙이 약간 부정확 한 경우에도 클라이언트 측에서이를 수정할 수 있습니다.

그렇기 때문에 모든 클라이언트가 원하는 것을 할 수 있는 분산 환경에서 실제로 Git 리포지토리에 대한 명명 규칙이 없습니다.
( 'repo의 베어 양식' '에 xxx.git대해 " "를 제외하는 경우 제외 ) REST 서비스에 대한 이름 지정 규칙이있을 수 있지만 ( " REST API에 대한 이름 지정 규칙 지침이 있습니까? " 와 유사 ), 이는 별도의 문제입니다.xxx


4
좋은 지적. 그러나 클라이언트 측에서 repo 이름을 수정하면 이름 지정 규칙이 도움이 될 것입니다. 당신은 생각하지 않습니까? 처음부터 컨벤션을 따른다면 왜 고쳐야합니까? 아마도 메이븐은 나에게 많은 영향을 미쳤을 것이다.
Adrian M

1
@AdrianM 내 요점은 : 네, 명명 규칙은 유용하지만 Git 또는 GitHub와는 관련이 없으며 특정 리포지토리와 관련이있는 모든 것이 있습니다. 따라서 귀하의 질문에 대한 대답은 "아니요, 자식 리포지토리에 대한 명명 규칙이 없습니다"입니다.
VonC

8

어쩌면 그것은 Java 및 C 배경을 보여주는 것일 수도 있지만 이름의 구두점보다 CamelCase (CapCase)를 선호합니다. 내 작업 그룹은 이러한 이름을 사용하여 리포지토리에 포함 된 앱 또는 서비스 이름과 일치 할 수 있습니다.


6
이 게시물은 드문 편이며 개인적으로 선호하는 것은 아니지만 Java의 프로젝트 이름은 낙타의 경우와 일치하는 편이 있다는 이점을 여전히 언급하고 있습니다. 여기서 다운 보트가 단순한 이름 지정 바이어스가 아니라고 확신합니까?
eremzeit

1
동의했다. 다른 답변은 camelCase의 단점에 대해 설명하지만 Java 세계에서는 camelCase가 더 나은지 결정하는 것이 합리적입니다. 특히 Windows 세계를 행복하게 모르는 프로젝트의 경우.
Michael Scheper 2016 년

11
Pedantic 공공 서비스 발표 : PascalCase는 camelCase가 아닙니다.
MarredCheese

0

PHP 패키지를 만들 계획이라면 , 작곡가와 함께 사용할 수 있도록 Packagist 를 추가하고 싶을 것 입니다. Composer는 사용하기위한 명명 컨벤션 을 가지고 있습니다 vendorname/package-name-is-lowercase-with-hyphens.

JS 패키지를 만들 계획이라면 아마도 npm을 사용하고 싶을 것입니다. 이름 지정 규칙 중 하나는 패키지 이름 중간에 대문자를 허용하지 않는 것입니다.

따라서 PHP 및 JS 패키지가 lowercase-with-hyphensGitHub의 패키지와 동일하게 composer 또는 npm의 패키지를 사용 하고 이름 을 지정하는 것이 좋습니다 .

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.