목록기술 노트/Google Code Style Guide (14)
anothel의 지식 창고
12장 규칙 예외(Exceptions to the Rules)위에서 설명한 코딩 규칙들은 반드시 따라야 하는 필수 사항이다. 그러나 모든 좋은 규칙에 예외가 있듯이, 일부 경우에는 이러한 규칙에서 벗어날 수 있는 예외 상황이 있다. 여기서는 이러한 예외 사항에 대해 다룬다.12.1 기존의 스타일을 따르지 않는 코드 (Existing Non-conformant Code)이 스타일 가이드에 맞지 않는 기존 코드를 다룰 때는 규칙에서 벗어날 수 있다.가이드와 다른 방식으로 작성된 코드를 수정할 경우, 해당 코드의 로컬 규칙에 일관성을 맞추기 위해 이 가이드의 규칙에서 다소 벗어날 수 있다. 어떻게 해야 할지 확신이 서지 않을 때는 원 작성자나 현재 코드의 책임자에게 문의하는 것이 좋다. 일관성은 전체 코드뿐만..
11장 코드 형식 (Formatting)코딩 스타일과 형식은 다소 임의적일 수 있지만, 모든 사람이 같은 스타일을 사용하면 프로젝트를 훨씬 쉽게 이해할 수 있다. 개개인은 모든 형식 규칙에 동의하지 않을 수도 있고, 일부 규칙이 익숙해지는 데 시간이 걸릴 수 있지만, 모든 프로젝트 기여자가 규칙을 준수해야 서로의 코드를 읽고 이해하기 쉬워진다.코드를 올바르게 형식화하는 데 도움이 되도록, emacs 설정 파일을 제공하고 있다.프로젝트의 일관된 형식을 유지함으로써, 가독성이 향상되고 협업이 원활해진다.11.1 줄 길이 (Line Length)코드의 각 줄은 최대 80자를 초과하지 않도록 한다.이 규칙은 논란이 있을 수 있으나, 많은 기존 코드가 이미 이를 준수하고 있으며, 일관성을 유지하는 것이 중요하다...
10장 주석(Comments)주석은 코드 가독성을 유지하는 데 매우 중요하다. 다음 규칙들은 주석을 어디에 어떻게 작성해야 하는지를 설명한다. 하지만 항상 기억해야 할 점은, 최상의 코드는 주석이 필요 없는 코드, 즉 스스로를 설명할 수 있는 코드다. 변수와 타입에 명확하고 의미 있는 이름을 부여하는 것이, 이해하기 어려운 이름을 사용하고 그 의미를 주석으로 설명하는 것보다 훨씬 좋다.주석을 작성할 때에는 다음에 코드를 이해해야 할 독자를 염두에 두어야 한다. 후속 작업자가 당신의 코드를 쉽게 이해할 수 있도록 친절하게 작성하라. 그 독자가 나중에 바로 당신이 될지도 모른다.10.1 주석 스타일 (Comment Style)주석에는 // 또는 /* */ 구문을 사용할 수 있다. 단, 일관성을 유지해야 한다..
9장 명명 규칙(Naming)네이밍 규칙에서 가장 중요한 일관성 규칙은 이름을 통해 즉시 그 이름이 어떤 종류의 엔티티인지 알 수 있게 하는 것이다. 네이밍 스타일을 통해 타입인지, 변수인지, 함수인지, 상수인지, 매크로인지 등을 선언을 따로 확인하지 않고도 쉽게 알 수 있어야 한다. 우리 두뇌의 패턴 매칭 엔진은 이러한 네이밍 규칙에 크게 의존한다.네이밍 규칙은 다소 임의적일 수 있지만, 이 영역에서는 개인의 선호보다는 일관성이 더 중요하다. 규칙이 합리적이라고 느끼지 않더라도, 규칙은 규칙이므로 따라야 한다.주요 원칙타입명일반적으로 PascalCase 사용 (예: MyClass, AnotherType).변수명 및 함수명소문자로 시작하고 단어마다 대문자로 표기하는 camelCase 사용 (예: myVa..
8장 포괄적 언어(Inclusive Language)모든 코드에서, 네이밍 및 주석을 포함하여, 다른 프로그래머가 불쾌하거나 모욕적으로 느낄 수 있는 용어 사용을 피하고 포괄적 언어를 사용해야 한다. 예를 들어, "master"와 "slave", "blacklist"와 "whitelist", "redline" 등의 용어는 겉보기에는 중립적인 의미를 가질 수 있지만, 특정 집단에게는 불쾌하게 다가올 수 있으므로 사용하지 않는다.또한, 특정인을 지칭하지 않는 한 성 중립적인 언어를 사용해야 한다. 예를 들어, 성별이 지정되지 않은 사람을 지칭할 때는 "they"/"them"/"their"와 같은 단수형을 사용하며, 소프트웨어, 컴퓨터, 기타 사람이 아닌 것을 지칭할 때는 "it"/"its"를 사용한다.권장 ..
7장 기타 C++ 기능(Other C++ Features)7.1 Rvalue 참조 (Rvalue References)Rvalue 참조는 임시 객체에만 바인딩될 수 있는 참조 타입으로, && 구문을 사용한다. 예를 들어, void f(std::string&& s);는 std::string 타입의 rvalue 참조를 받는 함수를 선언한다. Rvalue 참조는 객체의 이동과 완벽한 전달을 가능하게 하여 성능 최적화에 유용하다.Rvalue 참조의 주요 사용 사례이동 생성자와 이동 할당연산자std::move를 이용해 rvalue 참조를 전달하면 복사 대신 값을 이동할 수 있어 성능을 크게 향상시킨다. 예를 들어, std::vector v1이 있을 때, auto v2(std::move(v1));는 대량의 데이터를 ..
6장 Google 특유의 테크닉(Google-Specific Magic)Google에서는 C++ 코드를 더욱 견고하게 만들기 위한 다양한 트릭과 유틸리티를 사용하며, 일반적인 C++ 관행과는 약간 다르게 코딩하는 방식도 있다. 이러한 기술들은 코드의 안정성과 유지보수성을 높이기 위한 목적으로 사용된다.Google이 사용하는 주요 기술과 관행유틸리티와 도구Google은 코드 품질을 높이기 위해 특정 유틸리티 라이브러리와 도구들을 사용한다. 예를 들어, Google Test와 Abseil 같은 라이브러리는 코드의 테스트와 유틸리티 기능을 추가하여 코드의 안정성을 높인다.모범 사례와 일관성Google은 모든 코드가 일관된 스타일과 규칙을 따르도록 함으로써, 팀의 규모와 관계없이 유지보수가 용이한 코드를 유지한..
5장 함수 (Functions)5.1 입력과 출력 (Inputs and Outputs)C++ 함수에서 출력을 제공하는 방식으로 반환값을 선호하는 것이 좋다. 반환값은 가독성을 높이며 성능도 유리한 경우가 많다. 다음은 함수의 입력과 출력에 관한 권장 사항이다.반환값과 출력 매개변수의 사용반환값출력을 제공할 때는 반환값을 우선으로 사용한다. 성능과 가독성이 좋다.출력 매개변수반환값 대신 출력 매개변수를 사용할 경우, 가능하면 참조를 사용하고 널이 될 수 있는 경우에만 포인터를 사용한다.함수 매개변수의 종류와 권장 사용 방식입력 매개변수보통 값 타입이나 const 참조로 전달한다.출력 및 입출력 매개변수비널(non-null)인 경우 참조로 전달하는 것이 좋다.선택적 매개변수:선택적 입력 매개변수는 std::..
4장 클래스 (Classes)클래스는 C++에서 코드의 기본 단위로, 광범위하게 사용된다. 클래스 작성 시 따라야 할 주요 권장사항과 피해야 할 점은 다음과 같다.4.1 생성자에서 작업하기 (Doing Work in Constructors)생성자에서는 몇 가지 중요한 사항을 주의해야 한다. 특히, 가상 메서드 호출과 에러를 신호할 수 없는 초기화를 피하는 것이 권장된다.가상 메서드 호출 피하기생성자에서 가상 함수가 호출되면, 이 호출이 파생 클래스의 구현으로 디스패치되지 않는다. 현재 클래스가 파생되지 않았다 하더라도, 향후 파생 클래스가 생길 경우 문제가 발생할 수 있어 혼란을 초래할 수 있다.에러 신호의 어려움생성자에서 발생한 오류를 신호하기가 쉽지 않다. 프로그램을 종료하는 방법은 모든 상황에서 적..
3장 스코핑 (Scoping)3.1 네임스페이스 (Namespaces)대부분의 코드에는 네임스페이스를 사용해야 하며, 네임스페이스 이름은 프로젝트 이름과 경로에 따라 고유해야 한다. using 지시문(e.g., using namespace foo)과 인라인 네임스페이스는 사용하지 않으며, 무명 네임스페이스는 내부 연결에서 다룬다.네임스페이스는 글로벌 스코프를 독립적이고 이름이 지정된 스코프로 분할해 이름 충돌을 방지하는 역할을 한다. 예를 들어, 두 프로젝트가 모두 전역 범위에서 Foo라는 클래스를 정의할 경우, 컴파일 또는 런타임에 충돌할 수 있다. 그러나 각 프로젝트가 네임스페이스를 사용하여 project1::Foo와 project2::Foo로 구분한다면, 충돌을 방지하면서 각 프로젝트 내부에서는 F..