RuboCop 규칙 개발 가이드라인

GitLab 코드베이스에서 RuboCop 규칙을 개발, 활성화, 관리하는 방법을 설명합니다.

코드베이스 스타일은 RuboCop 으로 정의하고 적용합니다. bundle exec rubocop --parallel 명령으로 로컬에서 위반 사항을 확인할 수 있습니다. CI에서는 static-analysis job이 자동으로 이를 검사합니다. 또한 Solargraph gem을 사용하여 지원되는 IDE에 RuboCop을 통합 할 수 있습니다. 아직 결정을 내리지 않은 RuboCop 규칙에 대해서는 Ruby 스타일 가이드 를 따라 관용적인 Ruby를 작성하세요. 리뷰어/메인테이너는 스타일에 대해 관대하게 접근하고 지나치게 엄격하지 않아야 합니다. 일부 RuboCop 규칙은 비활성화되어 있으며, 이 경우 리뷰어/메인테이너는 저자에게 어느 한 스타일을 사용하도록 요청해서는 안 됩니다. 두 가지 스타일 모두 허용되기 때문입니다. 이는 bike-shedding 의 여지를 남기기 때문에 이상적인 상황은 아닙니다. 이상적으로는 스타일 관련 토론, 사소한 지적, 혹은 리뷰에서의 불필요한 반복을 피하기 위해 모든 RuboCop 규칙을 활성화해야 합니다. GitLab Ruby 스타일 가이드 에는 리뷰에서 자주 언급되지만 강제되지 않는 스타일의 비포괄적 목록이 포함되어 있습니다. 또한 테스트 전용 스타일 가이드 및 모범 사례 도 별도로 제공됩니다. 인라인 규칙 비활성화 # 기본적으로 RuboCop 규칙은 인라인 비활성화 를 사용하지 않아야 합니다. 인라인 비활성화는 코드베이스에 적용하려는 합의된 코드 표준을 무효화하기 때문입니다. 인라인 비활성화를 반드시 사용해야 한다면, 규칙이 비활성화된 같은 줄에 코드 주석으로 이유를 제공하세요. 이 인라인 비활성화 주석 위에 추가 컨텍스트를 코드 주석으로 작성할 수 있습니다. 상세한 컨텍스트를 제공하기 위해 verbose한 코드 주석 대신 리소스(이슈, 에픽 등)로 연결하는 링크를 사용하세요. 임시 인라인 비활성화에는 rubocop:todo 를 사용하고 후속 이슈 또는 에픽을 링크하세요. 예시: # bad module Types module Domain # rubocop:disable Graphql/AuthorizeTypes class SomeType < BaseObject if condition # rubocop:disable Style/GuardClause # more logic... end object.public_send(action) # rubocop:disable GitlabSecurity/PublicSend end # rubocop:enable Graphql/AuthorizeTypes end end # good module Types module Domain # rubocop:disable Graphql/AuthorizeTypes -- already authorized in parent entity class SomeType < BaseObject if condition # rubocop:todo Style/GuardClause -- Cleanup via https://gitlab.com/