스타일 가이드와 규칙

• 규칙 : 은 곧 법. 엄격하고 꼭 지켜야 함
• 지침 : 권장사항과 모범 사례, 따르면 이득. 변형하여 적용해도 괜찮음
• 구글에는 프로그래밍 스타일 가이드가 정리되어 있음
  • 외부 조직에도 이를 쓰는 곳이 굉장히 많음 (cpp, python…)
• 구글의 프로그래밍 스타일 가이드에 담긴 결정들은 구글 코드베이스를 지속 가능하게 관리하기 위한 규칙들

8.1 규칙이 필요한 이유

• “좋은” 행동을 장려가고 “나쁜” 행동을 억제하기 위함
• 좋음과 나쁨은 주관적이고 무엇이 필요하냐에 따라 달라지므로, 조직마다 기준이 다를 수 있음
• 어휘 (즉 코딩 스타일)이 통일되면 엔지니어들은 코드를 표현하는 형식보다 담을 내용에 집중할 수 있음

8.2 규칙 만들기

• 먼저 생각해야 하는 것 : “어떤 목표를 이루려하지?”
• 목표에 집중하면 규칙이 따라옴
• 뭘 넣어야하지? 가 아닌 이게 왜 들어가야하지?

8.2.1 기본 원칙 안내

• 규모와 시간 양쪽 측면에서 탄력적인 엔지니어링 환경이 지속되도록 하는 것
• 규칙의 양을 최소화
• 코드를 읽는 사람에게 맞춤
• 일관되어야 함
• 오류가 나기 쉽거나 예상치 못한 동작을 유발하는 구조를 피함
• 꼭 필요하다면 실용성을 생각해 예외를 허용

규칙의 양을 최소화한다

• 규칙을 익히는 것 또한 비용
• 너무 자명한 규칙은 의도적으로 배제 (goto 사용에 대한 규칙은 없음)

읽는 사람에게 맞춘다

• 코드는 작성되는 횟수보다 읽히는 횟수가 더 많으면 시간이 갈수록 차이가 벌어짐
• 읽기 난해한 것보다 타이핑하기 지루한 것이 더 나음
  • 파이썬의 조건부 표현 (x = 3 if a % 3 else 4)은 금지하고 if문 사용권장 (if a%3: x=3 else: x=4)
• 읽기에 간단한 > 스기에 간편한
• 변수와 타입 이름을 서술식으로 더 길게 짓고 반복해서 타이핑
• JAVA, JS, C++ 가이드에는 오버라이드하는 메서드에는 오버라이드 어노테이션이나 키워드를 반드시 사용
• 목적은 “현 위치에서 추론하기” -> 다른 코드를 찾아보거나 참조할 필요 없이, 함수의 구현부를 들여다보지 않고도 호출 지점에서 무슨일이 벌어지는지를 명확히 이해할 수 있도록 해야 함

일관되어야 한다

• 구글은 코드스타일 뿐만 아니라 다른 인터페이스도 다 일치시켜서 시간을 허비하는 일을 줄임

일관성이 안겨주는 이점

• 우리가 제한한 특정 수치가 아니라 ‘단 하나의 답’만 사용한다는 일관성
• 일관성은 규모를 확장하기 쉽게 도와줌
• 인력을 늘리는 데도 도움이 됨
• 시간 관점에서도 탄력성을 보장

표준 정하기

• 구글의 파이썬 스타일 가이드의 indent는 한 때 2개였음… 구글에서 만든 코드를 사용할때 정말 극혐이었음 (대부분 공백을 4개 쓴다)
• 외부 세상도 중요함!

오류를 내기 쉽거나 예상과 다르게 동작할 여지가 있는 구조는 피하자

• 복잡한 기능에는 언뜻 봐서는 지나칠 수 있는 미묘한 함정이 숨어있을 수 있음 -> 버그 유발
• 구글에서는 파이썬의 리플렉션 (hasattr(), getattr())을 사용금지함
  • 근데 외부에는 또 쓰는곳도 많음!
• 고급 기능들은 기능을 잘 이해하고 활용하는 전문가에게는 이상적인 해법일 수 있지만 일반적으로는 이해하기 더 어렵고 널리 쓰이지 않음
• SRE에 중요함

실용적 측면을 인정하자

• 유도리 필요
• 일관성과 가독성을 희생해서라도 성능을 끌어올려야할 때가 있음
• 표준 라이브러리 기능, 윈도우 플랫폼 기능, 빌드과정에서 자동 생성된 코드 등에는 예외 적용 가능

8.2.2 스타일 가이드

• 위험을 피하기 위한 규칙
• 모범 사례를 적용하기 위한 규칙
• 일관성을 보장하기 위한 규칙

위험을 피하기 위한 규칙

• 구글의 스타일 가이드에는 기술적인 이유 때문에 반드시 써야 하거나 쓰면 안되는 언어 특성들에 관한 규칙들이 담겨있음
• 어떤 언어 특성은 사용하고 어떤 구조는 피해야 하는지

모범 사례 강제하기

• 코드 작성자가 주석을 어디에 어떻게 작성해야 하는지 명시함
• 작성자의 의도가 코드 자체에 명확하게 드러나지 않는 경우에는 의도를 주석으로 남겨야 함
  • switch문에서의 fall-through
  • 빈 catch 블록
  • 템플릿 메타프로그래밍
• 읽기 용이하게 하기 위해 소스 파일의 구조도 규칙으로 정의함
• 패키지, 클래스, 함수, 변수 드으이 이름을 짓는 규칙도 존재
• 포맷팅 규칙도 중요 -> 도구 사용 가능!
• 새로운 도입도 중요! (ex std::unique_ptr 도입)

일관성 구축하기

그 외…

• 구글 스타일 가이드에는 없는 것도 많음

8.3 규칙 수정하기

• 세월이 흘러가면 규칙은 변할 수 있음
• 구글 스타일 가이드의 규칙에는 각각의 결정을 뒤받침하는 근거를 명시해둠
  • 이는 나중에 변경이 필요할 때 도움이 됨

8.3.1 프로세스

• 스타일 가이드의 수정 대부분이 커뮤니티에서의 토론으로부터 출발
• 던져진 아이디어에 대해 커뮤니티에서 논의되고 피드백을 받음
• 커뮤니티의 검토를 거친 제안은 최종 승인 단계로 넘어감

8.3.2 스타일 중재자

• 구글의 스타일 가이드들은 언어별로 소유자 (언어용 라이브러리팀의 선임자이거나 언어 경험이 풍부한 오랜 구글 직원)가 따로 있어서 최종 결정과 승인을 책임짐
• 엔지니어링 측면의 트레이드오프를 논의하여 결정함
• 개인의 선호가 아닌 트레이드오프로 결정

8.3.3 예외

• 규칙을 따르기보다 예외를 인정하는 쪽이 이득이라고 판단될 때만 예외를 허용함

8.4 지침 (Guidance)

• 주요 언어의 입문서 (Primer)
• 구글의 “금주의 팁” 시리즈
• <언어이름>@Google101 수업 시리즈
• 유용한 참고 자료
  • 올바로 구현하기 어려운 주제에 관한 언어별 조언 (예: 동시성과 해싱)
  • 언어의 최신 버전에서 소개된 새로운 기능의 상세 설명과 구글 코드베이스에 적용하는 방법에 관한 조언
  • 구글 라이브러리가 제공하는 중요한 추상 개념과 데이터 구조 목록. 이미 만들어둔 구조를 새로 만드는 일을 방지해주고 “필요한 게 있는데 우리 라이브러리에서 이걸 뭐라고 부르는지 모르겠어”와 같은 질문에 답해줌

8.5 규칙 적용하기

• 교육
• 코드 리뷰
• 가독성 프로세스
• 자동화 도구 활용 (유용하나 만능은 아니다!)

8.5.1 오류 검사기

• Linter?
• C++ : clang-tidy
• JAVA : Error Prone

8.5.2 코드 포맷터

• Format on save
• 행렬 포맷팅은 사람이 더 잘하긴 함…
• 프리서브밋 검사로 포맷터를 반드시 사용하게 함
• C++: clang-format, Python: YAPF, Go: gofmt, …

8.6 마치며

• 코딩 스타일과 규칙은 성장하는 조직에 중요합니다!

8.7 핵심 정리

• 규칙과 지침의 목표는 시간과 확장 관점에서의 탄력성을 높이는 것이어야 합니다.
• 상황이 변하면 규칙도 달라져야 하니 규칙이 만들어진 근거 데이터를 알고 있어야 합니다.
• 모든 것을 규칙으로 강제해서는 안 됩니다.
• 일관성이 핵심입니다.
• 간으한 한 규칙들이 자동으로 적용되도록 해야합니다.