Google C++ Style Guide 번역 정리

차례

 

C++ Version - C++ Version	C++ Version - C++ Version
헤더 파일 - Header Files	자체 포함 헤더 - Self-contained Headers #define가드 - The #define Guard 사용하는 내용 포함 - Include What You Use 전방 선언 - Forward Declarations 인라인 함수 - Inline Functions include의 이름과 순서 - Names and Order of Includes
범위 - Scoping	네임스페이스 - Namespaces 내부 연계 - Internal Linkage 비 멤버 함수, 정적 멤버 함수, 전역 함수 - Nonmember, Static Member, and Global Functions 지역 변수 - Local Variables 정적 변수와 전역 변수 - Static and Global Variables 스레드 지역 변수 - thread_local Variables
클래스 - Classes	생성자에서의 작업 - Doing Work in Constructors 암시적 변환 - Implicit Conversions 복사 가능 및 이동 가능 유형 - Copyable and Movable Types 구조체 대 클래스 Structs vs. Classes 구조체 대 쌍 및 튜플 - Structs vs. Pairs and Tuples 상속 - Inheritance 연산자 오버로드 - Operator Overloading 접근 제어 - Access Control 선언 순서 - Declaration Order
함수 - Functions	입력 및 출력 - Inputs and Outputs 짧은 함수 작성 - Write Short Functions 함수 오버로딩 - Function Overloading 기본 인수 - Default Arguments 후행 반환 형식 구문 - Trailing Return Type Syntax
구글만의 특별한 마법- Google-Specific Magic	소유권과 스마트 포인터 - Ownership and Smart Pointers cpplint - cpplint
그 외의 C++ 기능 - Other C++ Features	Rvalue 레퍼런스 - Rvalue References Friends - Friends 예외 - Exceptions noexcept - noexcept Run-Time Type Information (RTTI) - Run-Time Type Information (RTTI) 형 변환 - Casting 스트림 - Streams 전위 증가와 전위 감소 - Preincrement and Predecrement const의 사용 - Use of const constexprt의 사용 - Use of constexpr 정수 타입들 - Integer Types 64비트 이식성 - 64-bit Portability 전처리기 매크로 - Preprocessor Macros 0과 nullptr/NULL - 0 and nullptr/NULL sizeof - sizeof Type Deduction (including auto) Class Template Argument Deduction Designated Initializers 람다 표현식 - Lambda Expressions Template Metaprogramming Boost Boost 그 의외 C++ 기능 - Other C++ Features Nonstandard Extensions Aliases
Inclusive Language
이름 규칙 - Naming	일반 이름 규칙 - General Naming Rules 파일 이름 - File Names 타입 이름 - Type Names 변수 이름 - Variable Names 상수 이름 - Constant Names 함수 이름 - Function Names 네임스페이스 이름 - Namespace Names 열거형 이름 - Enumerator Names 매크로 이름 - Macro Names 이름 규칙의 예외 - Exceptions to Naming Rules
주석 - Comments	주석 스타일 - Comment Style 파일 주석 - File Comments 클래스 주석 - Class Comments 함수 주석 - Function Comments 변수 주석 - Variable Comments 구현 주석 - Implementation Comments 구두점, 철자, 문법 - Punctuation, Spelling, and Grammar TODO 주석 - TODO Comments
포매팅 - Formatting	줄 길이 - Line Length ASCII가 아닌 문자 - Non-ASCII Characters 스페이스 대 탭 - Spaces vs. Tabs 함수 선언과 정의 - Function Declarations and Definitions 람다 표현식 - Lambda Expressions Floating-point Literals 함수 호출 - Function Calls 중괄호 초기화 목록 형식 - Braced Initializer List Format 조건문 - Conditionals 반복문과 switch문 - Loops and Switch Statements 포인터와 레퍼런스 표현식 - Pointer and Reference Expressions 불리언 표현식 - Boolean Expressions 리턴값 - Return Values 변수와 배열 초기화 - Variable and Array Initialization 전처리기 지시자 - Preprocessor Directives 클래스 포맷 - Class Format 생성자 초기화 리스트 - Constructor Initializer Lists 네임스페이스 포매팅 - Namespace Formatting 가로 공백 - Horizontal Whitespace 세로 공백 - Vertical Whitespace
규칙의 예외 사항 - Exceptions to the Rules	규칙을 지키지 않는 기존 코드 - Existing Non-conformant Code 윈도우 코드 - Windows Code

 

배경  - Background

 

C++은 구글의 많은 오픈소스 프로젝트에서 사용하는 주요 개발 언어 중 하나이다.

모든 C++ 프로그래머가 알고 있듯, C++ 언어에는 많은 강력한 기능이 있다. 하지만 이 기능들은 복잡함을 야기하고 결과적으로 코드를 버그가 발생하기 쉽고, 읽고 유지 관리하기 어렵게 만들 수 있다.

 

이 가이드의 목표는 C++ 코드 작성 시 해야 할 일과 하지 말아야 할 일을 자세하게 설명하여 복잡함을 관리하는 것이다. 이러한 규칙들은 기반 코드를 관리 가능한 상태로 유지하면서 코더가 C++ 언어 기능을 생산적으로 사용할 수 있도록 하기 위함이다.

 

'가독성'이라고도 하는 '스타일'은, C++ 코드를 관리하는 규칙이다. 스타일이라는 용어는 다소 잘못된 명칭이다. 이러한 규칙은 소스 파일 형식보다 훨씬 더 많은 것을 다룬다. 

 

구글에서 개발한 대부분의 오픈 소스 프로젝트는 이 가이드의 요구사항을 따른다.

이 가이드는 C++ 자습서가 아니다. 우리는 독자가 이 언어에 친숙하다고 가정한다.

 

우리의 기반 코드를 관리할 수 있게 유지하는 한 가지 방법은 일관성을 강제하는 것이다. 어떤 프로그래머라도 남의 코드를 볼 수 있고 쉽게 이해할 수 있는 것은 매우 중요하다. 일치된 스타일을 유지하고 컨벤션에 따른다는 것은 우리가 더 쉽게 "패턴 매칭"을 사용하여 다양한 기호들이 무엇을 의미하고 어떤 값이 변함없이 참인지를 추측할 수 있다는 것을 의미한다. 모두가 필수적으로 사용할 숙어와 패턴을 만들면 코드를 이해하는 것이 훨씬 쉬워진다. 가끔은 어떤 스타일 규칙을 바꾸자는 바람직한 논쟁이 있을 수 있지만, 그럼에도 불구하고 일관성을 유지하기 위해 규칙을 기존대로 유지한다.
이 가이드가 서술하는 또 다른 이슈는 C++의 기능이 비대해지고 있다는 것이다. C++은 많은 고급 기능이 있는 거대한 언어이다. 어떤 경우에 우리는 어떤 기능의 사용을 제한하거나 심지어 금지한다. 이것은 코드를 간단하게 유지하면서 그 기능들이 흔히 만들 수 있는 문제들과 오류들을 피하기 위해서다. 이 가이드는 이러한 기능들을 나열하고 왜 사용이 제한되었는지 설명한다.

아래 글 배경에서 참조
https://jongwook.kim/google-styleguide/trunk/cppguide.xml?

 

스타일 가이드의 목표  - Goals of the Style Guide

 

이 문서가 있는 이유는 무엇일까?

 

이 가이드가 도움이 되어야 한다고 생각하는 몇가지 핵심 목표가 있다. 이 목표가 앞으로 살펴볼 개별 규칙의 기초가 되는 근본적인 이유이다. 이러한 아이디어를 전면에 내세움으로써 토론의 근거가 되고 규칙이 적용되고 특정 결정이 내려진 이유를 더 넓은 커뮤니티에 더 명확하게 하기를 바란다.

각 규칙이 어떤 목표를 제공하는지 이해한다면 규칙을 포기할 수 있는 경우(일부는 가능할 수 있음), 가이드에서 규칙을 변경하기 위해 어떤 종류의 주장이나 대안이 필요한지 모든 사람에게 더 명확해야 한다.

 

현재 보고 있는 스타일 가이드의 목표는 아래와 같다.

 

1. 스타일의 규칙은 사람들의 영향력을 끌어당겨야 한다.
   • 스타일 규칙의 이점은 모든 엔지니어에게 이 규칙을 기억하도록 요청할 만큼 충분히 커야 한다. 이점은 규칙 없이 얻을 수 있는 코드베이스와 관련하여 측정되므로, 매우 해로운 관행에 대한 규칙은 사람들이 어쨌든 그렇게 할 가능성이 거의 없다면 여전히 작은 이점을 가질 수 있다. 이 원칙은 우리가 가지고 있는 규칙보다 우리가 갖고 있지 않은 규칙을 대부분 설명한다. 예를 들어, goto는 앞으로 나올 원칙들 중 많은 부분을 위반하지만 이미 매우 드물게 사용되기 때문에 스타일 가이드에서는 이에 대해 논의하지 않는다.
2. 작가가 아닌 독자를 위해 최적화해라.
   • 우리의 코드베이스(및 제출된 대부분의 개별 컴포넌트들)은 꽤 오랫동안 계속 될 것으로 예상된다. 결과적으로 코드를 작성하는 것보다 대부분의 코드를 읽는데 더 많은 시간이 소요된다. 우리는 코드를 작성할 때의 용이함보다는 코드베이스에서 코드를 읽고, 유지하고, 디버깅하는 우리의 평균 소프트웨어 엔지니어의 경험을 위해 최적화하기로 명시적으로 선택한다. "독자에게 흔적 남기기"는 이 원칙의 특히 일반적인 서브포인트이다. 코드의 스니펫에서 놀랍거나 비정상적인 일이 발생하는 경우(예: 포인터 소유권 이전), 사용 시점에 독자에게 텍스트 힌트를 남기는 것은 가치가 있다. (std::unique_ptr는 호출 지점에서 소유권 이전을 명확하게 보여준다)
3. 기존 코드와 일관성을 유지해라.
   • 코드베이스를 통해 일관되게 하나의 스타일을 사용하면 다른 (더 중요한) 문제에 집중할 수 있다. 일관성을 통해 자동화도 가능하다. 코드 형식을 지정하거나 #include를 조정하는 도구는 코드가 도구의 기대치와 일치할 때만 제대로 작동한다. 많은 경우에 "일관되게 하라"에 기인한 규칙은 "하나만 선택하고 그것에 대해 걱정하지 말라"로 요약된다; 이러한 점에서 유연성을 허용하는 것의 잠재적 가치는 사람들이 이에 대해 논쟁하게 만드는 비용보다 크다. 그러나 일관성에는 한계가 있다. 명확한 기술적 논쟁이나 장기적인 방향이 없을 때 좋은 타이브레이커이다. 로컬에서(파일당 또는 밀접하게 관련된 인터페이스 집합에 대해) 더 많이 적용된다. 일관성은 일반적으로 새로운 스타일의 이점이나 시간이 지남에 따라 새로운 스타일로 수렴하는 코드베이스의 경향을 고려하지 않고 이전 스타일로 작업을 수행하는 정당화로 사용되서는 안된다. 
4. 적절한 경우 광범위한 C++ 커뮤니티와 일관성 유지해라.
   • 다른 조직에서 C++를 사용하는 방식과 일치하는 것은 코드 기반 내에서 일관성을 유지하는 것과 같은 이유로 가치가 있다. C++ 표준의 기능이 문제를 해결하거나 일부 관용구가 널리 알려지고 받아 들여지면 그것을 사용하는 것이 좋다. 그러나 때로는 표준 기능과 관용구에 결함이 있거나 코드베이스의 요구 사항을 염두에 두지 않고 설계된 것일 수 있다. 이러한 경우(아래에 설명됨) 표준 기능을 제한하거나 금지하는 것이 적절하다. 어떤 경우에는 C++ 표준에 정의된 라이브러리보다 자체 개발 또는 타사 라이브러리를 선호하는데, 이는 코드 베이스를 표준 인터페이스로 전환하기에 불충분하거나 우세한점이 없는 경우이다.
5. 놀랍거나 위험한 구조를 피해라.
   • C++에는 얼핏 생각하는 것보다 더 놀랍거나 위험한 기능이 있다. 이러한 함정에 빠지는 것을 방지하기 위해 몇가지 스타일 가이드 제한이 있다. 이러한 제한에 대한 스타일 가이드 포기는 종종 프로그램의 정확성을 해칠 위험이 있기 때문에 높은 기준이 있다.
6. 일반적인 C++ 프로그래머가 유지 관리하기 까다롭거나 피하다고 생각하는 구성을 피해라.
   • C++는 코드에 도입되는 복잡성 때문에 일반적으로 적절하지 않을 수 있는 기능이 있다. 널리 사용되는 코드에서, 더 복잡한 언어 구성을 사용하는 것이 적합할 수 있다. 왜냐하면 더 복잡한 구현의 이점은 사용법에 따라 크게 증가하고, 복잡성을 이해하는 데 드는 비용은 코드베이스의 새로운 부분을 작업할 때 다시 지불할 필요가 없기 때문이다. 의심스럽다면 프로젝트 리드에게 문의하여 이러한 유형의 규칙에 대한 면제를 요청할 수 있다. 이는 코드 소유권과 팀 구성원이 시간이 지남에 따라 변하기 때문에 우리 코드베이스에 특히 중요하다. 일부 코드로 작업하는 모든 사람이 현재 코드를 이해하고 있다 하더라도 그러한 이해가 지금부터 몇 년동안 유지된다는 보장은 없다.
7. 우리의 규모를 염두해 둬라.
   • 1억 라인이 넘는 코드베이스와 수천 명의 엔지니어가 있기 때문에 한 엔지니어의 실수와 단순화는 많은 사람들에게 비용이 많이 들 수 있다. 예를 들어 전역 namespace를 오염시키는 것을 피하는 것이 특히 중요하다. 수억 줄의 코드베이스에서 걸친 이름 충돌은 작업하기가 어렵고 모든 사람이 전역 namespace에 무언가를 넣으면 피하기 어렵다.
8. 필요할 때 최적화를 양보해라.
   • 성능 최적화는 때때로 이 문서의 다른 원칙과 충돌하는 경우에도 필요하고 적절할 수 있다.

 

이 문서의 목적은 합리적인 제한으로 최대한의 지침을 제공하는 것이다.

항상 그렇듯이 상식과 좋은 취향이 우선해야 한다. 이를 통해 우리는 개인 취향이나 팀의 취향뿐만 아니라 전체 Google C++ 커뮤니티의 확립된 규칙을 구체적으로 참조한다.

영리하거나 특이한 구조를 사용하는 것에 대해 회의적이며 꺼려하라: 금지 사항이 없다고 해서 계속 진행할 수 있는 것은 아니다.

자신의 판단에 따르고 확실하지 않은 경우 주저하지 말고 프로젝트 리드에게 추가 정보를 요청하라.

 

앞으로 한 주제씩 포스팅하면서 구글 C++ 스타일 가이드 번역과 추가 정보 나의 생각을 정리해 나갈 예정입니다.

 

감사합니다!

 

https://google.github.io/styleguide/cppguide.html#Goals