Google C++ Style 썸네일형 리스트형 [Google C++ Style Guide] 8. Formatting Google C++ Style Guide 8. Formatting코딩 스타일과 포맷팅은 매우 제멋대로지만, 모든 사람이 같은 스타일을 사용한다면 프로젝트는 보다 쉬워진다. 포맷팅 규칙에 동의하지 않는 사람도 있겠지만, 금방 익숙해질 것이며 모든 사람의 코드를 보고 이해하기 쉽도록 한다. A. Line Length (라인 길이)각 라인은 80자를 넘지 않는다. 이 룰은 논쟁의 여지가 있지만, 기존 코드는 모두 이를 고수하고 있으며, 일관성이 중요하다. 장점 :이 룰을 좋아하는 사람들은 그들의 윈도우 창을 강제로 리사이징하는 것은 무례하고, 더 길 필요가 없다고 주장한다.일부는 다수 코드 윈도우 창을 나란히 세워 사용하기 때문에 윈도우 창을 더 넓히고 싶어하지 않는다. 최대 윈도우창의 가로 사이즈를 고려해서.. 더보기 [Google C++ Style Guide] 7. Comments Google C++ Style Guide 7. Comments (주석)주석은 코드를 가독성 있게 유지시킨다. 다음의 규칙들은 무엇을 작성할지 어디에 작성할지를 기술한다. 주석은 매우 중요하지만, 최선의 코드는 self-documenting이라는 것을 기억해라. 타입과 변수 이름을 센스 있게 지으면 주석으로 설명하는 것보다 훨씬 낫다. A. Comment Style (주석 스타일)// 또는 /* */ 를 사용하며, 일관성 있게 사용한다. // 또는 /* */ 를 사용하지만, //이 더 많이 사용된다.어떻게 사용하고 어떤 스타일로 사용하든지 일관성 있게 사용한다. B. File Comments (파일 주석)각 파일의 시작은 저작권(copyright)을 게시하며, 파일 내용에 대한 설명을 기술한다. Legal.. 더보기 [Google C++ Style Guide] 6. Naming Google C++ Style Guide 6. Naming A. General Naming Rules (일반적인 네이밍 규칙)함수 이름, 변수 이름, 파일 이름은 설명적이어야 한다. 생략을 피한다. 타입과 변수는 명사이며 함수는 ‘명령형’ 동사 이어야 한다. How to Name (이름 짓는 방법)이름은 가능한 설명적으로 짓는다. 공간 절약이 중요한 게 아니라, 코드를 즉시 보고 이해할 수 있어야 한다. 아래 예는 좋은 이름들이다.int num_errors; // Good.int num_completed_connections; // Good. 모호한 약어나 의미를 알 수 없는 임의의 문자를 사용하지 않는다.int n; // Bad – 의미 없음int nerr; // Bad – 모호한 약어int n_com.. 더보기 [Google C++ Style Guide] 5. Other C++ Features Google C++ Style Guide 5. Other C++ Features A. Reference Arguments (참조자 인자)참조자로 넘겨지는 모든 파라미터는 const 를 붙인다. 정의 :C에서는 함수의 파라미터를 수정할 필요가 있을 때, 포인터를 사용한다, 예, int foo(int *pval). C++에서는 그 대안으로 파라미터를 참조자로 선언할 수 있다. int foo(int &val). 장점 :참조자로 파라미터를 정의하면, (*pval)++과 같은 지저분한 코드를 피할 수 있다. 복사 생성자와 같은 함수들에게 필요하다. 참조자는 포인터와 달리 NULL값이 불가능하다. 단점 :참조자는 포인터 의미가 아닌 변수 구문을 갖기에 혼동될 수 있다. 결론 : 함수 파라미터에서 모든 참조자는 co.. 더보기 [Google C++ Style Guide] 4. Google-Specific Magic Google C++ Style Guide 4. Google-Specific Magic구글이 C++ 코드를 보다 견고하게 만드는 트릭과 유틸리티와 다른 곳에서 보던 코드와는 다른 구글만의 C++코드를 보여준다. A. Smart Pointers포인터를 사용해야 한다면, boost::scoped_ptr를 사용한다. 객체가 STL 컨테이너를 담는 경우처럼 특정 조건 하에서는 std::tr1::shared_ptr 만을 사용해야 한다. 절대 auto_ptr을 사용하면 안된다. ‘스마트’ 포인터는 포인터처럼 동작하는 ‘객체’이다. 따라서 메모리를 스스로 관리한다. 예를 들어scopted_ptr이 파괴될 때 포인터가 가리키는 객체를 소멸시킨다. shared_ptr도 마찬가지이지만, 참조 카운팅 방식 스마트 포인터로 참.. 더보기 [Google C++ Style Guide] 3. Classes Google C++ Style Guide 3. ClassesA. Doing Work in Constructors (생성자의 역할)일반적으로, 생성자는 멤버 변수를 초기화 해야 한다. 초기화가 복잡하면 Init() 함수를 사용한다. 정의 : 생성자의 구현부에 초기화를 수행한다. 장점 : 타이핑이 편리하다. 클래스가 초기화 되었는지 걱정할 필요가 없다. 단점 : 아래와 같은 문제가 있다.- 생성자에서 예외를 사용하는 에러 처리가 어렵다. (예외가 발생하면 안된다)- 초기화 작업에 실패가 발생하면 객체는 생성되지 않으며 불명확한 상태가 된다.- 만약 가상 함수를 콜한다면, 서브 클래스로 전파되지 않는다.- 만약 누군가 전역 변수를 만든다면, 생성자는 main() 이전에 호출될 것이며, 생성자 코드내에서 암시적.. 더보기 [Google C++ Style Guide] 2. Scoping Google C++ Style Guide 2. ScopingA. Namespaces (네임 스페이스).cc(.cpp) 파일에 이름없는 namespace를 사용한다. 프로젝트나 경로를 기반으로 namespace의 이름을 정한다. using 명령어를 사용하지 않는다. 정의 :이름 공간(Namespace)은 개체를 구분할 수 있는 범위를 나타내는 말로 일반적으로 namespace는 전역공간에서 이름 충돌을 하지 못하도록 하는데 유용하다. 장점 :namespace는 (계층적) 네임 축(axis of naming) 을 제공하며 클래스에 의해 제공되는 네임 축도 포함된다. 예를 들어 전역 공간에 두 개의 다른 프로젝트에 클래스 Foo가 존재한다면, 런타임 또는 컴파일 타임 시 충돌이 발생한다. 이 충돌을 방지하기 .. 더보기 [Google C++ Style Guide] 1. Header Files http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml 위의 내용을 제 나름대로 번역한 겁니다.물론 오역 굉장히 많습니다 --; C++ 프로그래밍 적인 면에서 스콧 마이어스의 Effective C++에서 보던 내용이 많고,스타일은 리눅스 계열의 스타일인것 같아 제가 당장 쓰기 어려운 것도 많습니다.그런것은 제 나름대로 사용하면 될 것 같고,문서에도 나와있지만, 정답이 없는 코딩 스타일의 경우는 일관성이 가장 중요해 보입니다. 긴 내용이라 챕터별로 올립니다. (전문은 파일 첨부) Google C++ Style Guide 1. Header Files 단위 테스트와 main()함수만 있는 .cpp파일을 제외하고 일반적으로 모든 .cpp파일은 .h파일과 .. 더보기 이전 1 다음