2016-06-22 1 views
-2

저는 초보자입니다. 경험이 많았고 함께 많은 일을 한 90 년대 팀이 만든 매우 복잡한 소스 코드에 액세스 할 수있었습니다. 소스 코드는 훨씬 더 많은 헤더 파일을 포함하는 약 60 개의 서로 다른 .c 파일로 구성되며 대부분이 몇 줄의 코드로 구성됩니다. 다른 사람이 #define, #include, #if (#endif), #else, #undef, #pragma 등에서뿐만 아니라 일부 구조 (struct) 같은 지침으로 구성하면서 하나 개 포함 된 파일은 헤더에있는 main 함수를 정의합니다. 또한 당신은 (더 많거나 적은 동일한 #define 등이다)를 enum을 찾아 constchar, int는, short는, long는, floatdouble 등이의큰 응용 프로그램에 하나의 머리글 만 사용할 수 있습니까?

없음 사용되지 않습니다 같은 몇 가지 변수 .c 파일하지 않는 한 실제로 그것을 필요로합니다. .c 파일의 대부분은 이러한 헤더 파일을 많이 포함하므로이를 추적하기가 어렵습니다. 내 생각은 모든 헤더 파일을 하나의 단일 헤더 파일에 넣어서 Unihead.h이라고합니다. 모든 변경 작업을 수행하려는 경우 문제를 찾기 위해 최대 15 개의 헤더 파일을 검사해야합니다. 그 많은 헤더 파일의 이점을 볼 수 없습니다. 각 소스 파일에 헤더가있는 것은 정상적인 것입니다 (Soccer.cSoccer.h이라는 헤더를 가짐). 하나의 헤더 파일을 얻은 경우 간단한 검색을 통해보다 효과적으로 찾을 수 있으므로 프로세스가 훨씬 원활하게 처리됩니다. 이런 일을하는 아래쪽면이 있습니까? (나는 어쨌든 추적 할 주석을 추가 할 것이다)

답변

1

이것은 좋은 생각이라고 생각하지 마십시오.

모든 60 .c 파일을 하나의 파일로 결합 할 수도 있습니다. 그러나이 소스 및 헤더 파일 구조에는 많은 이유가 있습니다. 프로젝트 구조를 이해하려고 노력해야합니다.

+0

예. 모든 c.-files를 하나에 추가 할 수는 있지만 더 명확하게 분할되어 있습니다. 모든 것을 체계적으로 정리합니다. 비록 헤더 파일, 내 생각에 코드에서 좋은 체계적인 시스템되지 않습니다. 일반적으로 코드 자체도 상당히 엉망입니다. 예를 들어, .c 파일 안에 #define과 같은 지시어가 있습니다. 많은 변수뿐만 아니라 ... – Thomas

0

이런 식으로 일을하는 아래쪽 면도 있습니까?

특히 모 놀리 식 헤더 파일이 커질 경우 컴파일 시간이 증가 할 수 있습니다.

또한 이름 충돌의 위험이 적습니다. 헤더는 일부 함수를 선언 할 수 있으며 소스 파일 중 하나 (현재 해당 헤더를 포함하지 않음)는 동일한 이름을 가진 static 함수를 가질 수 있습니다. 이는 컴파일 문제를 일으킬 수 있습니다. 마찬가지로 소스 파일은 헤더 파일에서 다르게 정의 된 유형의 이름으로 내부 사용을위한 유형을 정의 할 수 있습니다.

1

잘 쓰여진 C 코드는 주 파일이 맨 위에있는 피라미드처럼 배열되어 있습니다. 종속성 (함수 호출, 열거 형, const 등)은 피라미드에서 아래로 실행됩니다. 결코 위쪽으로. 이렇게하면 나중에 코드를 유지, 확장 및 테스트하는 데 도움이됩니다.

헤더 파일을 모두 축소하면 피라미드가 축소됩니다. 또한 C 파일을 축소 할 수도 있습니다.

헤더 파일은 특정 모듈의 노출 된 부분을 의미합니다 (일반적으로). 예 : 이것들은 "public function", "public consts"등을 포함합니다. "private consts", "private macros"등과 같은 코드는 c- 파일에 저장하는 것이 좋습니다. 이것이 C 파일에 "#defines"가 포함 된 이유입니다.

나에게는 코드가 잘 작성된 코드처럼 들립니다. 예 : 각 파일의 헤더 (피라미드 가능), 노출 된 코드 만 포함하는 작은 헤더

추가하는 것 이상으로 파괴하지 않도록주의하십시오.

관련 문제