IT박스

STL / Boost C ++ 코딩 스타일이 다른 사람들과 크게 다른 이유는 무엇입니까?

itboxs 2020. 11. 22. 19:15
반응형

STL / Boost C ++ 코딩 스타일이 다른 사람들과 크게 다른 이유는 무엇입니까?


저는 상당히 신인 C ++ 프로그래머이지만 언어에 대한 제한된 경험으로 인해 대부분의 표준 C ++ 스타일 가이드 라인 (예 : Google C ++ 스타일 가이드 라인 )은 stl 및 boost 라이브러리에 구현 된 것과 반대됩니다.

예를 들어, C에서 클래스 이름 ++ 표준 라이브러리와 부스트는 밑줄 (예 : 단어를 분리로 항상 소문자입니다 std::vector, boost::unordered_map, std::map::const_iterator), 대부분의 스타일 가이드 반면, 나는 C에 대한 본 적이 ++ (예 : 낙타 표기법 스타일을 향해 경향 TcpConnection또는 Int32).

메서드에도 동일하게 적용됩니다. 표준 라이브러리와 Boost는 클래스 (예 std::map<>::get_equal("foo"):) 와 동일한 스타일을 메서드와 함수에 사용하는 반면 대부분의 스타일 가이드는 pascalCase 또는 CamelCase를지지합니다.

대부분의 사용자가 핵심 라이브러리에서 사용되는 규칙을 준수하는 Ruby와 같은 언어와 대조하면 표준 C ++ 라이브러리와 다른 모든 코드간에 이러한 차이가 있다는 것이 이상하게 보입니다.

이것이 왜인지 아는 사람이 있습니까?

편집 : 명확히하기 위해 실제 구현 스타일이 아닌 피상적 인 텍스트 스타일 (대 / 소문자 구분, 밑줄 사용 등)에 대해 이야기하고 있습니다.


밑줄과 소문자는 Bjarne Stroustrup이 "The C ++ Programming Language"에서 추론 한 스타일입니다. 내가 정확하게 기억한다면 그는 영어가 모국어가 아닌 국제 사회에서 더 읽기 쉬웠 기 때문에 이름의 밑줄이 선호되어야한다고 주장했다. 그의 의견이 사실인지 아닌지는 모르겠지만 그것이 기원이라고 생각합니다.

여기에 그가 바로이 주제를 논의하는 그의 FAQ 링크가 있습니다.

http://www.stroustrup.com/bs_faq2.html# 헝가리어

특히 관심이있는 부분을 설명하는 스 니펫 :

elementCount 및 ElementCount와 같은 대안보다는 식별자 (예 : element_count)에서 단어를 구분하기 위해 밑줄을 사용하는 것을 선호합니다. 일반적으로 매크로 용으로 예약되어 있으므로 모두 대문자로 된 이름 (예 : BEGIN_TRANSACTION)을 사용하지 마십시오. 매크로를 사용하지 않더라도 누군가 헤더 파일을 흩뿌 렸을 수 있습니다. 유형 (예 : Square 및 Graph)에는 초기 대문자를 사용합니다. C ++ 언어 및 표준 라이브러리는 대문자를 사용하지 않으므로 Int가 아닌 int이고 String이 아닌 string입니다. 이렇게하면 표준 유형을 인식 할 수 있습니다.


Bjarne Stroustrup 옆에 좋은 이유가 있습니다. 펑터를 사용할 때 함수처럼 보이기를 원합니다.

그러나 CamelCase 스타일 가이드를 사용하면 클래스 이름의 첫 번째 문자에 대문자를 사용하고 메서드의 첫 번째 문자에 LowerCase를 사용하여 클래스를 메서드 및 함수와 구분할 수 있습니다.

이것은 C ++ 알고리즘 스타일 프로그래밍과 일치하지 않습니다. 펑터를 함수와 구별 할 이유가 없기 때문에 펑터를 사용하고 싶을 때 (일반적으로 원하는 경우) C ++ 및 stl 코딩 스타일을 사용하는 것이 좋습니다.


진정으로 필요한 유일한 규칙은 알려진 문제를 방지하도록 설계된 규칙입니다.

  • 전 처리기 이름 및 전 처리기 이름에만 ALL_CAPS (밑줄 및 숫자 포함)를 사용하십시오. (아마도) 전처리 기가 아닌 식별자와 전 처리기 이름 사이의 충돌로 인해 발생하는 문제를 추적하는 것은 어려울 수 있지만 아직 해결하기는 더 어렵습니다.
  • 밑줄로 식별자를 시작하지 말고 식별자 내부에 이중 밑줄이 없어야합니다. 그것들은 구현을 위해 예약되어 있습니다.

그 이상으로 일관성을 유지하고 너무 까다롭게 굴지 마십시오. 코딩 표준은 "작은 일에 땀을 흘리지 마십시오"라는 규칙 # 0을 염두에 두어야합니다. 너무 많은 코딩 표준이 작은 일을 방해합니다.

Google의 C ++ 표준에 관한 한 최고는 아닙니다. C 플러스 또는 마이너스 표준에 가깝습니다. 예를 들어 상수가 아닌 참조에 의한 통과를 금지합니다.

참고 URL : https://stackoverflow.com/questions/13881915/why-does-the-stl-boost-c-coding-style-differ-so-much-from-everyone-elses

반응형