Google coding guide
•
4 recomendaciones•3,871 vistas
구글 코딩 가이드 C++ 지침을 정리해봤습니다. 모든 지침을 따를 필요는 없지만 본인에게 유용한 지침이 있다면 잘 활용해보세요~
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Google coding guide
Similar a Google coding guide (20)
Google coding guide
- 1. C++
- 2. http://blog.naver.com/ruvendix 코딩 가이드를 알아보기 전에 개발 속도를 향상시키고 하나의 대화 수단이 된다!
- 3. http://blog.naver.com/ruvendix 코딩 가이드를 알아보기 전에 자신만의 코딩 가이드를 만들어도 되지만! 개발 경험이 부족하다면 이미 존재하는 코딩 가이드를 따르자! 적어도 int a; 이런 건 이제 그만두자!
- 4. 코딩 가이드를 알아보기 전에 구글은 실력이 뛰어난 개발자들이 있는 기업! 물론 코딩 가이드에는 정답이 없다! 스스로 장단점의 기준을 잡아서 판단해야 함! ※ 모든 내용을 소개하지는 않음 ※ ※ 모든 내용은 아래에 있는 사이트를 참고! ※ http://jongwook.kim/google-styleguide/trunk/cppguide.xml
- 7. http://blog.naver.com/ruvendix #define 방어 단일 헤더 파일도 존재하지만! .cc와 .h는 운명공동체! ※ .cc는 UNIX의 C++ 파일 ※ #pragma once 대신! #define 방어를 사용하라! 소스 파일을 source(src) 또는 script 등 폴더를 만들어서 모으고! 소스 파일의 경로에는 그 폴더를 생략한 경로를 작성 (즉, 기본 폴더는 생략) 헤더 파일은 include(inc) 또는 header 등으로 폴더를 만듬!
- 8. http://blog.naver.com/ruvendix 전방 선언 전방 선언보다 #include를 활용하라! 전방 선언을 이용하면 불필요한 #include를 줄일 수 있으나! 실질적인 성능 개선 효과는 거의 없음! 하지만 컴파일 타임을 줄이는 효과는 있음!
- 9. http://blog.naver.com/ruvendix 인라인 함수 함수가 10줄 이하면 인라인 함수로 만들어라! 하지만 과도한 인라인 함수는 프로그램을 느리게 만들 수 있음! 선택문, 반복문, 가변 인자, 가상 함수, 재귀 함수는 인라인 불가! 어차피 인라인 함수는 컴파일러 또는 IDE가 알아서 판단! 인라인 메서드는 헤더 파일에서 처리하되, 인라인 메서드가 많아지면 –inl.h에 따로 모아라! 매크로 함수보다는 인라인 함수를 이용! ※ IDE는 통합 개발 환경을 뜻함 ※
- 10. http://blog.naver.com/ruvendix 매개변수의 순서 매개변수는 입력 -> 출력 순서! 입력 매개변수는 값을 참조만 하려는 목적! 출력 매개변수는 값을 변경시키려는 목적! 입력은 주로 일반 변수, const 참조자이고 출력은 주로 포인터가 됨! 새로운 매개변수가 추가되어도 이 순서는 지켜야 함! 하지만 자신만의 스타일이 있다면 꼭 따를 필요는 없음!
- 11. http://blog.naver.com/ruvendix 포함시키는 순서 #include의 순서를 지키면 가독성이 향상된다!
- 13. http://blog.naver.com/ruvendix namespace C++은 namespace가 중요하다! namespace는 주로 프로젝트의 이름! using namespace std; 이런 거 금지! 대신 using 선언과 namespace 별명은 사용 가능! 인라인 namespace 금지! 헤더 파일에는 이름 있는 namespace만 사용!
- 15. http://blog.naver.com/ruvendix 중첩 클래스 멤버 클래스는 중첩 클래스에서만 사용 가능! 당연한 얘기지만 멤버 클래스를 사용하려면 중첩 클래스 자체를 포함해야 함!
- 16. http://blog.naver.com/ruvendix 전역 함수 전역 함수 대신 static을 사용하라! 정말로 전역 함수를 사용하고 싶다면 되도록이면 이름 없는 namespace를 활용하라! 모든 파일에서 사용할 함수가 필요하다면 루트 클래스나 #include를 활용하라!
- 18. http://blog.naver.com/ruvendix 전역 함수 이름 없는 namespace 활용! 이름 없는 namespace는 static처럼 작동함!
- 19. http://blog.naver.com/ruvendix 전역 변수 전역 변수 대신 대신 static을 사용하라! 정말로 전역 변수를 사용하고 싶다면 POD를 다룰 때만 사용하라! ※ POD는 Plain Old Data, C 형식의 구조체를 뜻함 ※
- 20. http://blog.naver.com/ruvendix 지역 변수 지역 변수는 선언과 동시에 초기화하라! 변수는 서로 관련이 있는 것들끼리 모아라! 반복자는 그냥 반복문 안에서 만들어라! 반복문에서 생성자와 소멸자는 한 번만 호출되도록 만들어라!
- 22. http://blog.naver.com/ruvendix 생성자 생성자에서는 복잡한 초기화를 삼가라! 복잡한 초기화는 Init() 같은 메서드로 작업하라! 생성자에서 가상 함수를 호출하지 마라! 생성자를 복잡하게 만들면 디버깅이 힘들다!
- 23. http://blog.naver.com/ruvendix 초기화 필드(멤버 변수)는 생성자에서 초기화하라! 필드는 구성원 초기화(멤버 이니셜라이저)를 이용해서 초기화하라! C++11 이상이라 해도 되도록이면 생성자를 이용하라!
- 24. http://blog.naver.com/ruvendix explicit 변환 생성자에는 무조건 explicit을 사용하라! 변환 생성자는 explicit으로 묵시적 형변환을 막아야 함! 복사 생성자는 특별한 경우가 아니라면 explicit을 사용하지 마라!
- 25. http://blog.naver.com/ruvendix 복사 생성자 정말 필요할 때만 복사 생성자를 사용하라! 복사 생성자 대신 Copy() 같은 함수를 만들어라! 복사 생성자는 개념 자체가 복잡해서 가독성이 저하될 수 있음! STL에서 객체를 자주 입출력할 때 얕은 복사가 우려되면 이동 생성자를 이용하라!
- 26. http://blog.naver.com/ruvendix 복사 생성자 기본 복사 생성자 및 기본 대입 연산자를 사용하지 않겠다고 알리는 매크로 함수
- 27. http://blog.naver.com/ruvendix 생성자 위임과 상속(C++11 이상) 생성자 위임과 상속을 활용하라! 생성자 위임과 상속은 소스 코드를 줄이는 효과가 있다! 처음 보면 좀 헷갈리지만 익숙해지면 편하다!
- 28. http://blog.naver.com/ruvendix 생성자 위임과 상속(C++11 이상) 생성자 위임은 구성원 초기화의 소스 코드를 줄이는 효과가 있다!
- 29. http://blog.naver.com/ruvendix 생성자 위임과 상속(C++11 이상) 자식 클래스만의 필드가 있다면 따로 초기화해야 한다는 단점이 있음!
- 30. http://blog.naver.com/ruvendix 구조체 단순히 정보만 필요할 때는 구조체를 활용하라! POD로 사용할 거라면 메서드를 정의하면 안됨! 생성자, 소멸자, 접근 메서드 정도는 가능! 그 외의 다른 기능이 필요하다면 클래스로 만들어라!
- 31. http://blog.naver.com/ruvendix 클래스 상속 상속은 되도록이면 public 상속을 사용하라! protected나 private 상속은 신중히 판단하라! 상속될 가능성이 있는 클래스는 virtual로 만들어라! 가독성을 위해 가상 함수는 virtual을 전부 다 붙여라!
- 32. http://blog.naver.com/ruvendix 연산자 오버로딩 되도록이면 연산자 오버로딩은 삼가라! 연산자 오버로딩은 프로그램을 더 복잡하게 만들 수 있다! 비교, 대입 등은 그냥 메서드를 따로 만들어라! 되도록이면 함수 객체 정도로만 사용하라!
- 33. http://blog.naver.com/ruvendix 접근 제어 정보 은폐를 위해 필드는 private으로 만들어라! 상속 관계라면 필드를 protected로 만들어라! 필드는 접근 메서드(Get, Set)로 이용하라! static const 필드는 public으로 만들어라!
- 34. http://blog.naver.com/ruvendix 선언 순서 가독성을 위해 선언 순서를 지켜라!
- 35. http://blog.naver.com/ruvendix 선언 순서(C++11 이상 포함) 선언 순서를 지키면 가독성이 향상된다! typedef enum static 또는 const 생성자 소멸자 메서드 필드(static 또는 const 제외) public -> protected -> private
- 36. http://blog.naver.com/ruvendix 함수의 길이 함수의 길이가 40줄이 넘어가면 나눌 수 있는지 고민하라! 함수의 길이가 너무 길어지면 알고리즘 파악이 힘들다! 최대한 중복을 줄이면서 단위 작업 형태로 만들어라!
- 38. http://blog.naver.com/ruvendix 소유권과 스마트 포인터(C++11 이상) 구글은 스마트 포인터로 std::unique_ptr을 사용한다! std::unique_ptr은 동적 객체와 소유권이 1:1 관계지만… std::move()로 소유권 이전은 가능하다! std::shared_ptr, std::auto_ptr, scoped_ptr, linked_ptr은 사용하지 마라!
- 40. http://blog.naver.com/ruvendix 참조자 인자 참조자 인자는 되도록이면 const를 사용하라! 참조자는 실수로 원본의 값을 변경할 확률이 높다! 값을 변경할 목적이라면 포인터를 인자로 넘겨라!
- 41. http://blog.naver.com/ruvendix r-value 참조 r-value 참조는 std::move()를 사용하라! r-value 참조자, std::forward, std::move_iterator, std::move_if_noexcept는 사용하지 마라! STL에서 동적 객체의 오버헤드가 심할 때는 이동 생성자를 이용하라!
- 42. http://blog.naver.com/ruvendix 오버로딩 오버로딩은 되도록이면 생성자에서만 사용하라! 단순히 매개변수만 달라진다면 그냥 템플릿을 사용하거나 AddInt(), AddDouble() 이렇게 함수를 만들어라! 오버로딩은 함수의 기능이 완전히 달라질 때만 사용하라!
- 43. http://blog.naver.com/ruvendix 기본 인자 기본 인자는 되도록이면 무시하라! 기본 인자를 사용하면 오버로딩 문제로 굉장히 복잡해진다! 기본 인자를 이용하고 싶으면 오버로딩을 이용하거나 함수를 새로 만들어라! 가변 인자 정도는 기본 인자를 사용해도 된다!
- 44. http://blog.naver.com/ruvendix 가변 길이 배열 가변 길이 배열은 되도록이면 무시하라! 가변 길이 배열과 alloca()는 사용하지 마라! 정말 사용하고 싶으면 scoped_ptr, scoped_array를 사용하라!
- 45. http://blog.naver.com/ruvendix friend friend는 생각보다 정보 은폐를 파괴하지 않는다! friend를 자주 사용하면 가독성에 문제가 있는 건 맞음! 하지만 의외로 장점도 많다! 간단한 테스트를 할 때는 사용하라! 컨트롤 클래스에서도 꽤 쓸만하다!
- 46. http://blog.naver.com/ruvendix 예외 처리 C++ 방식의 예외 처리는 되도록이면 삼가라! try throw catch는 되도록이면 사용하지 마라! 스택 되감기 때문에 디버깅이 더 힘들어질 수 있다! 하지만 처음부터 C++ 예외 처리를 이용하는 프로젝트도 있으므로 프로젝트의 방향에 따라 유연하게 적응하라!
- 47. http://blog.naver.com/ruvendix RTTI RTTI를 사용한다는 건 프로그램이 불안정하다는 것! 실제로 가리키고 있는 객체를 확인한다는 건 프로그램의 설계에 문제가 있다는 뜻! 간단한 테스트를 할 때는 사용해도 괜찮음!
- 48. http://blog.naver.com/ruvendix 형식 캐스팅 static_cast를 많이 사용하라! static_cast는 C의 형식 캐스팅 연산자보다 안전하다! const_cast는 const 속성을 제거하고 싶을 때 사용하라! dynamic_cast는 안전성을 확인할 때만 사용하라! reinterpret_cast는 포인터 변환에서 사용하라!
- 49. http://blog.naver.com/ruvendix 스트림 가독성을 위해 C언어의 입출력을 사용하라! cout과 cin은 연산자 오버로딩 때문에 디버깅이 힘들어질 수 있다! C언어의 입출력은 서식 지정자가 있기 때문에 디버깅이 쉽다! iostream만 있어도 printf()를 이용할 수 있다!
- 50. http://blog.naver.com/ruvendix 증감 연산자 반복문에서 반복자는 전위 증감 연산자를 사용하라! 전위 증감 연산자가 후위 증감 연산자보다 기계어가 더 짧다! 큰 차이는 없지만 전위 증감 연산자를 사용하는 쪽으로 고려하라!
- 51. http://blog.naver.com/ruvendix const 안전성을 위해 const는 적극적으로 사용하라! const는 귀찮은 문제가 생길 수 있지만 안전성 측면에서는 좋다! mutable은 쓸만하지만 스레드에서 문제가 생길 확률이 높다!
- 52. http://blog.naver.com/ruvendix constexpr(C++11 이상) 컴파일 타임에 상수가 필요하다면 constexpr을 사용하라! const는 런타임에서 값이 바인딩(고정)되지만 constexpr은 컴파일 타임에서 값이 바인딩된다! 따라서 int num_list[Length()] 이런 게 가능!
- 53. http://blog.naver.com/ruvendix 정수 형식 정수는 되도록이면 int를 사용하라! 다른 정수 형식이 필요하다면 stdint.h를 이용하라! 되도록이면 unsigned는 사용하지 마라! for (unsigned int i = foo.Length()-1; i >= 0; --i) 이렇게 실수할 확률이 높다! unsigned는 최솟값이 0이라는 사실을 잊지 말자!
- 54. http://blog.naver.com/ruvendix 64비트 이식성 64비트 이식성을 가지려면 intptr_t를 사용하라! intptr_t는 32비트와 64비트일 때 크기가 달라진다! intptr_t의 unsigned 버전인 size_t를 사용하려면 %z 서식 지정자를 사용하라!
- 55. http://blog.naver.com/ruvendix 64비트 이식성 intptr_t를 32비트와 64비트에 적용하려면 inttypes.h를 포함해서 입력에는 SCNdPTR을, 출력에는 PRIdPTR을 이용해야 함!
- 56. http://blog.naver.com/ruvendix 매크로 매크로 함수 대신 인라인 함수를 사용하라! 매크로 상수는 열거형, const로 대체할 수 있다! 매크로는 #define 방어에만 사용하자! 비주얼 스튜디오인 경우 _DEBUG와 _NDEBUG 정도는 가능하다!
- 57. http://blog.naver.com/ruvendix NULL(C++11 이상 포함) 형식에 따라 적절한 NULL을 사용하라! 정수는 0을, 실수는 0.0으로 초기화하라! 포인터는 NULL 또는 nullptr로 초기화하라! char는 ‘0’을, 문자열은 “”으로 초기화하라!
- 58. http://blog.naver.com/ruvendix sizeof 형식보다는 식별자를 sizeof에 사용하라! 식별자는 변할 가능성이 거의 없지만 형식은 언제든지 변할 가능성이 높다! 배열을 가리키는 포인터인 경우 sizeof를 사용하지 마라! 그냥 포인터를 이용해서 배열의 크기를 구하는 함수를 따로 만들어라!
- 59. http://blog.naver.com/ruvendix auto(C++11 이상) auto는 지역 변수로만 사용하라! auto를 자주 사용하면 가독성이 저하되지만 적절한 auto는 소스 코드를 간결하게 만들 수 있다! 전역, namespace, 클래스의 필드로는 사용하지 마라! auto를 이용한 중괄호 초기화도 하지 마라! 함수의 반환 형식에도 사용하지 마라!
- 60. http://blog.naver.com/ruvendix auto(C++11 이상) auto를 STL에 이용하면 반복자를 쉽게 선언할 수 있다!
- 61. http://blog.naver.com/ruvendix 중괄호 초기화(C++11 이상 포함) 중괄호 초기화를 적극적으로 사용하라! 중괄호 초기화는 소스 코드를 간결하게 만들 수 있다! C++11 이상부터는 std::initializer_list를 이용한 초기화도 가능하다!
- 62. http://blog.naver.com/ruvendix 중괄호 초기화(C++11 이상 포함) C++11 이상부터는 중괄호 초기화가 확장됨!
- 63. http://blog.naver.com/ruvendix 람다 표현식(C++11 이상) 람다 표현식은 되도록이면 무시하라! 람다 표현식을 잘 사용하면 소스 코드가 간결해질 수 있다! 하지만 잘못 사용하면 소스 코드가 굉장히 복잡해질 수 있다! 자신이 없다면 람다 표현식, std::function, std::bind를 사용하지 마라!
- 65. http://blog.naver.com/ruvendix 공통 규칙 이름은 약자를 피하고 상세하게 작성하라! 자주 사용되는 약자는 사용해도 괜찮음! 하지만 과도한 생략은 오히려 더 혼란스럽게 만듬!
- 66. http://blog.naver.com/ruvendix 파일 이름 파일 이름은 전부 소문자로 작성하라! 파일 이름은 _ 또는 –을 사용해서 단어를 구분하라! 폴더 또는 디렉토리 이름은 일관성만 유지하라! 관련이 있는 파일끼리 모아야 쉽게 파악할 수 있다!
- 67. http://blog.naver.com/ruvendix 형식 이름 형식 이름은 전부 대문자로 시작하라! 형식 이름은 대문자로 구분하라! 예) class TestSimpleClass 클래스, 구조체, typedef, 열거형에 적용!
- 68. http://blog.naver.com/ruvendix 변수 이름 변수 이름은 전부 소문자로 작성하라! 변수 이름은 _을 사용해서 구분하라! 구조체는 이 규칙을 따른다! 전역 변수를 쓴다면 g_를 붙여라! 예) int apple_count
- 69. http://blog.naver.com/ruvendix 상수 이름 상수 이름은 Konstant의 약자인 k를 접두사로 사용하라! 상수 이름은 형식 이름처럼 대문자로 구분하라! 예) const int kMaxStage ※ Konstant는 상수라는 뜻 ※
- 70. http://blog.naver.com/ruvendix 함수 이름 함수 이름은 전부 대문자로 시작하라! 함수 이름은 대문자로 구분하라! 프로그램이 종료되는 함수는 OrDie를 붙여라! 접근 함수인 get(), set()은 소문자로 만들어서 다른 함수와 구분하라! 예) void TestFunction(int argument), get_field(void), ExitOrDie(void)
- 71. http://blog.naver.com/ruvendix namespace 이름 namespace 이름은 전부 소문자로 작성하라! namespace 이름은 프로젝트 이름을 사용하라! Namespace 이름은 _을 사용해서 구분하라! 예) namespace good_project
- 72. http://blog.naver.com/ruvendix 열거형 이름 열거형 이름은 전부 k를 접두사로 사용하라! 열거형 이름을 매크로 상수처럼 사용하는 프로젝트가 있다면 그냥 그 프로젝트를 따르되, 충돌이 발생하면 이 규칙을 적용하라! 열거형 이름 작성 규칙은 상수 이름과 동일하다! 예) enum TestEnum { kOneEnum, kTwoEnum }
- 73. http://blog.naver.com/ruvendix 매크로 이름 매크로 이름은 전부 대문자로 작성하라! 매크로 이름은 _을 사용해서 구분하라! 예) #define MAX_STAGE 100
- 75. http://blog.naver.com/ruvendix 공통 주석 주석은 알고리즘 및 사용법 위주로 설명하라! 과도한 주석은 필요 없다! 누구나 알고 있는 내용을 주석으로 작성할 필요는 없다! 예) count++; // count의 값이 1증가됩니다. 맞춤법 및 쉼표, 마침표 등을 활용하라!
- 76. http://blog.naver.com/ruvendix 파일 주석 모든 파일에 머리말을 주석으로 작성하라! 파일 주석은 저작권, 파일 설명 순서로 설명하라! 더 이상 사용하지 않는 함수는 “DEPRECATED” 또는 “폐기” 등 표시를 하라!
- 77. http://blog.naver.com/ruvendix 파일 주석 이런 식으로 모든 소스 파일에 주석을 작성하라!
- 79. http://blog.naver.com/ruvendix 그 외의 나머지 소스 코드의 한 줄은 80자이내로! ASCII를 사용하라! 다국어가 필요하면 UTF-8을 사용하라! 탭 대신 스페이스를 사용하라!
- 80. http://blog.naver.com/ruvendix 그 외의 나머지 함수의 선언은 되도록이면 한 줄에서 끝내라! 한 줄이 넘어가면 보기 좋게 정리하라! if가 한 줄이면 if (true) return;이렇게 작성하라! 비어있는 반복문은 continue로 한 줄에 표현하라! while (true) continue