C에서 다른 행에 함수 유형 및 메소드 이름을 배치하는 이유

방금 회사에서 시작했으며 첫 번째 코드 검토에서 스타일 설명 중 하나는 반환 유형과 메서드 이름이 다른 줄에 있어야한다는 것입니다. 예를 들어

void foo() {
}

이것이어야한다

void
foo() {
}

나는 항상 첫 번째 스타일을 사용해 왔으며 사람들이 왜 두 번째 스타일을 사용하는지 개인 취향 이외의 다른 이유가 있는지 궁금했습니다. 나는 첫 번째가 가독성을 전혀 손상시키지 않는다고 생각합니다. C 프로그래머와 대규모 오픈 소스 프로젝트에서 다른 하나보다 공통적인가?

사람들이 왜 두 번째 스타일을 사용하는지 개인 취향 이외의 다른 이유가 있는지 궁금하십니까?

그것은 C의 초기 시절에 인기가 있었던 스타일이기 때문에 그 이유는 그것이 오랫동안 그렇게 해왔고, 그렇게 보이는 많은 코드를 가지고 있기 때문일 수 있습니다. 모두가 익숙합니다. 기업 모멘텀만큼 개인적인 취향은 아닙니다.

또 다른 이유는 함수 이름이 항상 첫 번째 열에서 시작하기 때문입니다. 리턴 유형은 길이가 다양하고 다소 복잡 할 수 있습니다. 유형을 자체 행에두면 함수 이름을 쉽게 찾을 수 있습니다.

회사에 스타일이 설정되어 있으면 코딩 표준 문서가있을 수도 있습니다. 물어보세요. 이 선택에 대한 이유를 설명 할 수 있으며 사본을 보유하면 향후 검토에서 유사한 문제를 피하는 데 도움이됩니다.

이것은 내가 찾은 유일한 코드 형식 규칙이며 실제로 가독성에 눈에 띄는 영향을 미치며 거의 노력이 필요하지 않습니다 (코드 편집기가 당신과 싸우지 않는다고 가정).

선언 / 정의에서 이름이 일관된 위치에 표시되도록하는 것이 프로그래밍 언어 설계에 좋습니다. 근거는 간단합니다. 이름의 시작 부분을 즉시 찾는 데 사용할 수있는 멋진 시각적 앵커 (중괄호 또는 매달린 들여 쓰기)가 있습니다. 이름을 찾기 위해 파일을 스캔 할 때 실제로 언어를 구문 분석 할 필요는 없습니다.

문서를 형식화 할 때와 동일합니다. 새 섹션을 시작할 때 이름을 굵은 글꼴로 표시하고 (종종 자체 줄에) 구분되지 않고 긴 문장으로 묻지 않습니다.

초기 C에는 매우 간결한 서명이있었습니다. 반환 유형은 선택 사항이며 인수 뒤에 인수 유형이 선언되었습니다. 이름도 매우 짧았습니다. 이는 때때로 이름을 상쇄하는 리턴 유형의 영향을 완화했습니다.

double dot(x, y);

여전히 소화가 잘됩니다.

C ++은 이것을 조금 더 악화시켰다. 인수 유형 스펙을 서명으로 이동하여 서명을 더 길게 만듭니다. 이 구문은 나중에 C 표준화 중에 채택되었습니다.

static struct origin *find_origin(struct scoreboard *sb,
                  struct commit *parent,
                  struct origin *origin)

소화가 쉽지 않지만 나쁘지는 않습니다. (깃에서 발췌)

이제 길고 설명적인 이름과 매개 변수화 된 유형의 현대적인 프로그래밍 관행을 고려하고이 선택이 어떻게 비참한 지 살펴보십시오. Boost 헤더의 예 :

template <class A1, class A2, class A3, class A4, class A5, class A6>
inline typename normalise<policy<>, A1, A2, A3, A4, A5, A6>::type make_policy(const A1&, const A2&, const A3&, const A4&, const A5&, const A6&)
{ 
   typedef typename normalise<policy<>, A1, A2, A3, A4, A5, A6>::type result_type;
   return result_type(); 
}

일반 코드를 작성하는 경우 이와 같은 서명은 평범하지 않습니다. 너무 열심히 시도하지 않고도 이것보다 훨씬 더 나쁜 사례를 찾을 수 있습니다.

C, C ++ 및 그 파생어 인 Java 및 C #은 읽기 가능한 선언 / 정의를 갖는 예외입니다. 인기있는 전임자와 동료 (Fortran, ALGOL, Pascal)는 결과 유형 앞에 이름을 올렸으며, 많은 후임자 (Go, Scala, TypeScript 및 Swift)는 더 읽기 쉬운 구문도 선택했습니다.

나는 C & C ++로 작업하는 19 년 동안이 스타일을 처음 만났습니다. 누군가이 악한 것을 발명 할 수있는 방법에 대해 거의 당황했습니다.

내가 찾을 수있는 유일한 (잠재적으로) 긍정적 인 점은 grep ^ FuncName을 사용하여 funciton 정의를 찾을 수 있다는 것입니다. 실제 도구를 싫어하는 일부 커뮤니티에서는 10 년 이상 전에 관련 요소가 될 수 있습니다 ... 내가 C ++ 및 클래스 멤버 기능에 적용되어이 특성도 죽이는 것을 보았습니다.

내 의견을 맞춰보세요. :)