정신없이 코딩을 하다가 어느순간 정신을 차려보니 헤더파일 목록 상태가 말이 아니다.
아주 처참하다
정리를 하려고 하는 순간 문득 헤더파일을 정리할 때도 순서가 있는지 궁금했다.
A.h, B.h
A.h와 B.h 라는 헤더파일이 있다. A.h에서는 B.h 내에 선언되어 있는 함수를 사용한다.
그런데 소스파일 안에서 B.h를 A.h 보다 먼저 포함하고 컴파일 해보자.
컴파일도 잘 되고 실행도 잘 된다!
그런데 여기서 순서를 바꿔서 A.h 다음에 B.h를 포함 해보자.
컴파일하면 컴파일 에러가 발생한다.
B.h가 먼저 있을때는 소스파일 내에서 A.h 내용 앞에 B.h 내용이 있기 때문에 컴파일 할 때 문제가 없다. 하지만 반대의 경우 A.h의 앞에는 필요한 B.h의 내용이 없어서 컴파일 에러가 발생한다.
헤더 파일 포함(#include) 순서
당연히 위의 A.h 안에 B.h을 포함하면 문제를 해결할 수 있다. 하지만 여기서 우리가 봐야할 부분은 헤더파일의 선언 순서이다. 초기 A.h 파일에 B.h를 선언하지 않아서 문제가 있는 상황인데도 불구하고 컴파일을 할 수 있었다. 지금은 컴파일이 잘 돼도 나중에는 안 되는 상황이 생길 수 있다. 이렇게 되면 초기에 문제를 인지하지 못하고 지뢰마냥 계속 가지고 가게된다.
계속 문제들이 쌓이다가 나중에 한번에 터지기 보다는 초기에 문제를 바로 발견하고 해결하는 것이 좋다. A.h을 B.h 보다 먼저 선언한 파일을 컴파일하면 에러를 보고 문제를 조기에 발견할 수 있고 바로 문제점을 고칠 수가 있다. 에러는 언제나 표면적으로 드러나야한다.
아래는 이런 에러를 조기에 발견할 수 있도록 해주는 최적의 헤더파일 선언 순서다.
1.
소스 파일과 짝을 이루는 헤더파일(The paired header file)
2.
프로젝트 내에서 작성한 다른 헤더파일(Other headers from your project)
3.
서드파티 헤더파일(3rd party library headers)
4.
정규 라이브러리 헤더파일(Standard library headers)
만약 헤더파일들이 서로 같은 그룹에 속한다면 알파벳 순서로 정렬해주자.
이 방식으로 헤더파일들을 선언한다면 내가 정규 라이브러리 헤더 등 다른 헤더파일을 빼먹었다면 컴파일러가 조기에 알려줘서 바로바로 고칠 수가 있다.
아주 멀끔하고 단정해진(?) 헤더파일들의 모습
