스타일 가이드의 목표

스타일 가이드의 목표¶

왜 이 문서를 작성했을까요?

이 가이드가 충족해야 한다고 믿는 몇 가지 핵심 목표가 있습니다. 이는 개별 규칙의 근본적인 이유를 설명합니다. 이러한 아이디어를 부각함으로써, 논의를 구체화하고 더 넓은 커뮤니티가 규칙의 존재 이유와 특정 결정이 내려진 이유를 더 명확히 이해하도록 돕고자 합니다. 각 규칙이 어떤 목표를 지향하는지 이해하면, 어떤 규칙이 예외적으로 무시될 수 있는지(일부는 가능합니다), 그리고 가이드의 규칙을 변경하기 위해 어떤 논의나 대안이 필요한지 더 잘 알 수 있을 것입니다.

현재 우리가 생각하는 스타일 가이드의 목표는 다음과 같습니다:¶

스타일 규칙은 충분한 가치를 가져야 한다¶

스타일 규칙의 이점은 모든 엔지니어가 이를 기억하도록 요구할 만큼 충분히 커야 합니다. 이 이점은 해당 규칙이 없을 때의 코드베이스와 비교하여 측정됩니다. 예를 들어, 매우 해로운 관행에 대한 규칙이라도 사람들이 이를 거의 사용하지 않는다면 이점이 적을 수 있습니다. 이 원칙은 주로 우리가 규칙으로 지정하지 않은 부분을 설명합니다. 예를 들어, goto는 많은 원칙을 위반하지만, 이미 매우 드물기 때문에 스타일 가이드에서 이를 논의하지 않습니다.

작성자가 아닌 독자를 위해 최적화¶

우리의 코드베이스(및 대부분의 개별 코드)는 오랜 시간 동안 유지될 것으로 예상됩니다. 결과적으로, 코드를 작성하는 데 소비되는 시간보다 읽고, 유지보수하며, 디버깅하는 데 더 많은 시간이 소요됩니다. 따라서 우리는 코드를 작성하는 데의 편의성보다, 평균적인 소프트웨어 엔지니어가 코드를 읽고 유지보수하고 디버깅하는 경험을 최적화하는 것을 선택합니다. "독자를 위한 흔적을 남기라"는 이 원칙의 중요한 하위 요소입니다. 코드 스니펫에서 예상치 못하거나 특이한 일이 발생할 때(예: 포인터 소유권 이전), 사용 시점에 독자에게 텍스트 힌트를 남기는 것이 가치 있습니다. 예를 들어, std::unique_ptr는 호출 지점에서 소유권 이전을 명확히 보여줍니다.

기존 코드와의 일관성 유지¶

코드베이스에서 하나의 스타일을 일관되게 사용하면 더 중요한 문제에 집중할 수 있습니다. 또한 일관성은 자동화의 기반이 됩니다. 예를 들어, 코드의 포맷팅이나 #include를 자동으로 조정하는 도구는 코드가 도구의 기대와 일치할 때만 제대로 작동합니다. 많은 경우, "일관성 유지"에 따른 규칙은 "그냥 하나를 선택하고 고민하지 말자"로 요약됩니다. 유연성을 허용하는 잠재적인 가치는 사람들이 이를 두고 논쟁할 비용보다 작습니다. 그러나 일관성에는 한계가 있습니다. 기술적 논의나 장기적인 방향이 명확하지 않을 때, 일관성은 좋은 타협점이 될 수 있습니다. 이는 파일별, 또는 긴밀하게 관련된 인터페이스 집합에서 더 많이 적용됩니다. 그러나, 새로운 스타일의 이점을 고려하지 않고 오래된 스타일로 고수하려는 것은 정당화되지 않습니다. 시간이 지남에 따라 코드베이스가 새로운 스타일로 통합되는 경향이 있기 때문입니다.

C++ 커뮤니티와의 일관성 유지¶

다른 조직에서 C++을 사용하는 방식과의 일관성도 같은 이유로 중요합니다. C++ 표준의 기능이 문제를 해결하거나, 널리 알려지고 수용된 관용구라면 이를 사용하는 것이 적합합니다. 그러나 때로는 표준 기능과 관용구가 결함이 있거나, 우리 코드베이스의 요구를 고려하지 않고 설계된 경우도 있습니다. 이런 경우, 표준 기능을 제한하거나 금지하는 것이 적절합니다. 일부 상황에서는 표준 인터페이스 대신 자체 라이브러리나 타사 라이브러리를 선호할 수 있습니다. 이는 더 나은 성능 때문이거나, 표준 인터페이스로 전환할 가치가 충분하지 않다고 판단되었기 때문입니다.

놀라운 또는 위험한 구조를 피하기¶

C++에는 얼핏 보기에는 놀랍거나 위험한 기능이 있습니다. 이러한 함정에 빠지지 않도록 스타일 가이드에서 일부 제한을 둡니다. 이런 제한의 예외를 허용하는 경우에는 높은 기준이 요구됩니다. 이러한 규칙을 무시하면 프로그램의 올바름을 직접적으로 손상시킬 위험이 있기 때문입니다.

평균적인 C++ 프로그래머가 어렵거나 유지보수하기 힘든 구조를 피하기¶

C++에는 코드에 복잡성을 도입하기 때문에 일반적으로 적합하지 않은 기능이 있습니다. 널리 사용되는 코드에서는 더 복잡한 구현의 이점이 크게 활용되므로 복잡한 언어 구조를 사용하는 것이 더 적합할 수 있습니다. 그러나 새로운 코드 조각에서 이러한 복잡성을 이해하는 데 드는 비용은 항상 고려해야 합니다. 만약 의문이 있다면, 프로젝트 리드에게 규칙의 예외를 요청하는 것이 좋습니다. 특히 코드 소유권과 팀 구성원이 시간이 지남에 따라 바뀌는 경우, 현재 코드에 익숙한 사람이 나중에도 계속 이해할 수 있다는 보장이 없습니다.

대규모 코드베이스를 염두에 둡니다¶

1억 줄 이상의 코드와 수천 명의 엔지니어가 협력하는 코드베이스에서는, 한 엔지니어의 실수나 간소화가 전체에 큰 비용을 초래할 수 있습니다. 예를 들어, 전역 네임스페이스 오염을 방지하는 것이 특히 중요합니다. 수백만 줄의 코드베이스에서 네임스페이스 충돌은 다루기 어렵고, 이를 피하기 어렵기 때문입니다.

필요할 때는 최적화를 허용¶

성능 최적화는 때로는 다른 원칙과 충돌하더라도 필요하고 적절할 수 있습니다.

이 문서의 목적은 합리적인 제한을 통해 최대한의 가이드를 제공하는 것입니다. 항상 상식과 좋은 취향이 우선되어야 합니다. 여기서 말하는 "상식과 좋은 취향"은 개인적이거나 팀의 취향이 아니라, Google C++ 커뮤니티 전체에서 확립된 관례를 의미합니다. 영리하거나 특이한 구조에 대해 의심을 품고, 이를 사용하기를 주저하세요. 금지가 없다고 해서 이를 사용할 수 있다는 의미는 아닙니다. 판단력을 발휘하세요. 확신이 없으면 프로젝트 리드에게 추가적인 입력을 요청하는 것을 두려워하지 마세요.