C++ 을 배운지 꽤 오래 되었지만, 아직도 코드 리뷰를
통해 다른 개발자들의 코드를 볼 때면 한숨이 나오는 경우가 많습니다.
이런 경우가 반복되다 보니,
예전에 몇 가지 코딩 규칙 비슷하게 만들어놓은 자료가 있어 포스팅해 봅니다. 자료가 만들다 말아 내용이 중구난방이네요.. 앞으로도 계속 내용 보강해
나가겠습니다.
▤ 포인트 핸들
및 윈도우 핸들 체크
- 함수로 전달된 포인터 인자나, new
로 생성한 포인터 등 모든 포인터는 사용하기 직전 포인터 검사를 수행
- 가급적 STL 컨테이너를
사용해서 아예 포인터를 사용하지 않는 것이 정신건강에 이롭다. (STL 자체적으로 메모리 생성 및
소멸)
- 메모리 LEAK 을 막기
위해 SMART POINT 와 같은 Wrapper 클래스를
만든다.
- (윈도우 프로그램의 경우)윈도우 API 호출 직전 항상 윈도우 핸들이 정상인지 IsWindow 와
같은 함수로 검사한다.
▤ DRY(Don't Repeat Your Code)원칙
- 같은 코드를 여기 저기 중복해서 사용하지 말아야 한다. (☞ 실용주의 프로그래머 참고). 중복해서 사용할 경우 코드 량이
늘어날 뿐만 아니라 유지보수 cost 가 같이 늘어 나고,
추후 추가/개선/변경 등의 요구사항으로 인한
모듈 수정 시 여러 소스를 함께 수정해야 한다.
- 동일한 코드를 공용 루틴(함수)으로 개발 –
2~3줄 짜리 복잡한 if 문도 bool 를
리턴 하는 함수로 개발(☞ Refactoring
참고)
▤ 클래스간
종속성 최소화
- 대규모 프로젝트에서는 공통모듈이 변경되어도 이를 사용하는 모듈이
문제가 없도록 반드시 공통모듈은 인터페이스 기반(데이터가 없는,
virtual 가상함수로만 구성된)으로 구현한다.
(☞ The C++ Programming Language 참고)
- A 클래스 → B 클래스 → C 클래스를 사용할 경우 각 클래스는 자기가 직접 다루는 클래스(A
는 B, B 는 C) 만 알아야 한다. 즉 A 클래스는 C
클래스를 직/간접적으로 include 해서는
안되며 C 클래스의 변경으로 인해 A 클래스가 컴파일
되어서는 안 된다. A 클래스가 C 를 직접 접근할 경우가
있다면 B 클래스에 위임함수를 만들어 해결한다. (☞
실용주의 프로그래머 참고)
- B 클래스가 A 클래스로 어떤 데이터를 전달할 경우가
있다면(주로 이벤트 발생시 값을 전달하기 위해) A
클래스의 최소 인터페이스만을 B 클래스에 전달하여(COM
의 이벤트 소스 방식) 종속성을 최소화 한다.
(☞ Developer’s Workshop To COM and ATL 3.0 참고)
▤ 함수 인자
전달
- 함수의 인자는 최대 7개를
넘지 않아야 한다(☞ Code Complete 2
참고)
- 클래스 인스턴스를 함수 인자로 넘겨서는 안 된다(특히 함수 인자로 CString 을 넘기는 경우가 많음. CString → const CString& 나 CString*,
const char* 등으로 수정한다.
)
▤ 오류조건을
먼저 검사하여 오류 체크로 인해 코드 가독성이 떨어지지 않도록 하자.
- 특정 오류조건이 발생하면 더 이상 함수 수행에 의미 없을
경우, 이러한 오류 조건들은 함수초입단계부터 먼저 확인해서 바로 리턴 한다
- 위와 같이 오류조건이 먼저 확인되면 프로그램 코드에서 if depth 가 줄어 들고 코드 읽기가 수월해 지는 장점이 있다.
|
Before
|
After
|
|
void CClass::OnTest()
{
...
...
if
(m_pWndMain)
{
DoSomething1();
}
...
if
(m_pWndMain)
{
DoSomething2();
}
}
|
void CClass::OnTest()
{
if (m_pWndMain ==
NULL)
return;
...
...
DoSomething1();
...
DoSomething2();
}
|
▤ 긴 함수
쪼개기 (☞ Refactoring 참고)
- 긴 함수는 작은 여러 개의 함수로 쪼갠다(Refactoring 책에 의하면 2-3줄 짜리 함수로까지 쪼개어서
코드 가독성을 높이도록 하고 있음)
- 작은 함수로 쪼개다 보면,
작은 함수를 재활용하게 될 수 있고
- 긴 함수보다 코드 읽기가 수월해 지며
- 결국 유지보수가 쉬워진다
▤ enum 값 선언
시 _START, _END 를 활용하자(☞ CODE COMPLETE2 참고)
- enum 으로 선언된 값들을 변수나 for loop 를
이용하여 반복 계산할 경우가 종종 있는데 이 경우 enum 시작과,
끝을 나타내는 값을 enum 선언에 포함하면 유용하게 사용할 수 있다.
- 추후 enum 에 값을
추가해야 할 경우 _END 값을 사용한 배열은 코드 변경없이 크기가 늘어남
- For 루프 등에 _START, _END 을 사용할 수
있어 유지 보수에 유리
|
Before
|
After
|
|
enum WEEK_NAME
{
SUNDAY =
0,
MONDAY = 1,
TUESDAY =
2,
WEDNESDAY =
3,
THURSDAY =
4,
FRIDAY =
5,
SATERDAY =
6,
};
int nWeeks[SATERDAY + 1];
}
|
enum WEEK_NAME
{
WEEK_STAR =
0,
SUNDAY =
0,
MONDAY = 1,
TUESDAY =
2,
WEDNESDAY =
3,
THURSDAY =
4,
FRIDAY =
5,
SATERDAY =
6,
WEEK_END =
6,
};
int nWeeks[WEEK_END + 1];
|
▤ 복잡한
제어문을 가진 루틴을 피하자
- If 문은 2 depth 이상 들어 갈 경우 refactoring 하라 (☞ CODE COMPLETE2)
① 대부분 코드를 제대로 이해하지 못해 복잡한 코드를 작성하고
있다.
② 개발자 90%는 2 depth 이상 들어가는 if 문장을 이해하지 못한다
- IF~ELSE IF ~ELSE IF ~ ….
ELSE 가 길게 이어질 경우
SWITCH 문으로 바꾼다
- IF 문이 길게 늘어 질 경우 함수로 분리한다
- C++ 의 factory 개념으로 상속을 이용한 클래스를
만드는 방법도 활용
