반응형
위에 설명된 coding conventions은 필수적이다. 하지만 좋은 rules 같이 몇몇은 가끔 예외를 가지며 여기서 논의한다.
Existing Non-conformant Code
이 style guide에 맞지 않는 코드를 다룰 때 이 rule를 벗어날 수도 있다.
만약 이 guide에 의해 소개된 것보다 다른 specification을 위해 작성된 code를 수정한다면, 해당 code에서 local convention에 일관성을 유지하기 위해 이러한 rule으로 부터 벗어나야만 할 수도 있다. 만약 이것을 어떻게 해야하는지가 의심스럽다면, 원작자 또는 현재 code 책임자에게 물어보자. consistency는 local consistency를 또한 포함한다는 것을 기억한다.
Windows Code
Window programmers는 Window headers와 다른 Microsoft code에서 convention에서 유래된 본인들만의 coding conventions을 개발해왔다. 누구든 code를 쉽게 이해하도록 하기를 원하기에 어떤 platform에서 모든 사람이 작성하는 C++ guide는 하나다.
일반적인 Window style 에 익숙하다면 일어버릴 수도 있는 몇몇 guidline을 다시 강조할만한 가치가 있다:
- Hungarian notation (예를 들어, naming an integer iNum)를 사용하지 말자. Google naming convention을 사용하며, source file에는 .cc extension을 포함한다.
- Windows는 primitive type을 위한 많은 synonyms를 정의하는데, DWORD, HANDLE 같은 것들, etc. 이는 완전히 사용 가능하며 권장된다. Window API functions을 호출할 때 이러한 타입을 사용하는 것에는. 심지어 근본적인 C++ type에 가깝게 유지한다. 예를 들어, LPCTSTR 대신 const TCHAR*를 사용한다.
- Miscrosoft Visual C++를 compile 할 때, warning level 3 이상으로 설정하며 모든 warnings을 error로 간주한다.
- #pragma once를 사용하지 않는다; 대신 standard Google include guards를 사용한다. include guards에서 path는 project tree의 top과 연관되어야만 한다.
- 만약 절대적으로 사용해야만 하는 것이 아니라면, #pragma와 __declspec 같은, nonstandard extensions은 사용하지 않는다. __declspec(dllimport)와 __declspec(dllexport) 사용은 가능하다; 하지만 DLLIMPORT와 DLLEXPORT 같은 macros를 통해 사용해야만 하며 code가 공유된다면 쉽게 extension을 disable 할 수 있어야한다.
하지만, Windows에서 rules을 어길 필요가 있는 몇 가지가 존재한다.
- 일반적으로 multiple implementation inheritance의 사용은 강력히 지양한다; 하지만, COM 과 몇몇 ATL/WTL class를 사용할 때는 필요하다. COM 또는 ATLWTL classes와 interfaces를 implement하기 위해 multiple implementation inheritance를 사용할 수도 있다.
- exceptions를 사용하지 말아야함에도, ATL과 몇몇 STLs에서 널리 사용되며 Visual C++에서 제공하는 코드들도 그렇다. ATL를 사용할 때, _ATL_NO_EXCEPTION을 정의해 exception을 disable 해야만 한다. STL에서 exception을 disable할 수 있는지를 조사해야만 하지만, 그렇지 않은 경우, compiler에서 exception을 켜도 괜찮다(이것은 STL를 compile하기 위한 것이다. 여전히 code에서는 exception을 작성하지 않아야한다)
- precomiled header에서 동작하는 일반적인 방식은 header file을 각 source file의 젤 위에 포함하는 것이며, 일반적으로 StdAfx.h 또는 precompile.h 같은 이름을 가진다. 다른 project에서 쉽게 공유되도록 code를 만들기 위해 (precompile.cc에서는 제외) 명시적으로 파일을 include하는 것을 피하고 자동으로 file을 include하는 /FI compiler option을 사용한다.
- Resource headers는 resource.h 이름이며 macro만 포함하는데, 이 style guideline에 맞출 필요가 없다.
반응형
'C++ > Google C++ Style Guide' 카테고리의 다른 글
| Comments (2) | 2025.06.22 |
|---|---|
| Naming (1) | 2025.06.19 |
| Other C++ Features (0) | 2025.05.26 |
| Google-Specific Magic (0) | 2025.05.26 |
| Functions (1) | 2025.05.25 |