저장소에서 코드 포맷터를 주기적으로 실행하는 것은 좋지 않습니까?

코드를 체크 아웃하고 코드 포맷터를 실행하며 변경된 것이 있으면 변경 사항을 커밋하고 다시 푸시하는 cron 작업을 만들려고합니다.

자동 포맷터를 사용하는 대부분의 프로젝트는 git hook에 넣지 만 몇 시간마다 자동으로 수행하면 각 개발자가 git hook을 설치해야하는 부담이 사라집니다.

나는 여전히 모든 사람이 깨끗하고 형식이 좋은 코드를 작성하도록 장려하고, 작성한 코드가 다시 포맷 될 때 시스템이 자동으로 개발자에게 핑 (ping)을 할 수있게하므로 앞으로 어떻게해야할지 알게 될 것이다.

멋지게 들리지만 봇이 아닌 코드 변경을 담당하는 사람들을 선호합니다.

또한 이러한 변경 사항이 아무런 영향을 미치지 않는지 확인하고 싶습니다. 예를 들어, 속성과 메서드를 알파벳 순서로 정렬하는 규칙이 있습니다. 이는 WCF 계약의 WSDL 파일에서 데이터 및 메소드 순서와 같이 기능에 영향을 줄 수 있습니다 .

대신 팀의 모든 사람이 팀의 표준에 따라 편집기 또는 IDE 내부에서 직접 현재 코드 파일 (또는 선택한 부분) 에 자동 코드 형식을 적용하는 것이 실제로 쉬워 지도록 노력하고 싶습니다 . 이를 통해 팀 구성원은 형식화 방법 및시기에 대해 더 많은 제어 권한을 부여하고, 최종 양식으로 커밋되기 전에 코드를 검사하고 , 형식화가 완료된 후가 아닌 코드를 테스트 할 수 있습니다.

모든 또는 대부분의 팀 구성원이 동일한 편집기를 사용하는 경우 너무 어렵지 않아야합니다. 모든 사람이 다른 것을 사용한다면, 팀이이를 지원하는 한, 당신의 접근 방식이 두 번째 최선의 해결책 일 수 있습니다. 그러나 야간 자동 빌드 및 각 자동 코드 수정 후에 실행되는 자동 테스트와 같은 추가 안전 조치를 설치하는 것이 좋습니다 .

사람들이 적절한 코드를 작성하지 못하게 할뿐만 아니라 VCS에서 코드 변경으로 표시 될 것이므로 (바람직한 코드를 사용하여) 코드 개발의 역사적 흐름을 숨기고 있기 때문에 나쁜 생각입니다. 더 나쁜 것은 모든 코드 포맷 작업 (실제로 코드가 변경 될 때마다)이 수동이든 자동화이든 버그를 일으킬 가능성이 있다는 것입니다. 따라서 포매터는 코드 검토, 단위 테스트, 통합 테스트 등을 몇 개월 후까지 거치지 않는 버그를 코드에 도입 할 수 있습니다.

나는 그것이 자동으로 코드 포매터를 실행하는 것이 좋은 생각이라고 생각하는 경향이 있지만, 그것은 단지 내 의견이다.

정기적으로 실행하지 않지만 가능한 경우 버전 제어가 커밋되기 전에 실행합니다.

와 자식 하는 후크 사전은 커밋 유용 할 것이다 그 일을. 일부 내장 많은 C 또는 C ++ 프로젝트에서 메이크 , 나는 몇 가지 추가하고 indent(같은 적절한 코드 포매터를 실행할 대상 indent또는 astyle) 및 참여자 실행 것으로 기대 make indent정기적으로합니다. BTW make에는 git hook이 설치되었는지 확인하기 위해 규칙을 추가 할 수도 있습니다 .

하지만 실제로, 그것은 더 인 사회 (A)보다 문제를 기술 한. 팀이 깨끗하고 멋진 형식의 코드를 커밋하기를 원하며 이는 프로젝트의 사회적 규칙입니다. (모든 사회적 문제에 항상 기술적 답변이있는 것은 아닙니다).

버전 관리는 주로 인간 개발자들 사이의 커뮤니케이션을 도와주는 몇 가지 도구입니다 (몇 달 후부터 여러분 자신을 포함). 소프트웨어에는 VC 나 형식이 필요하지 않지만 팀은 필요합니다.

BTW, 다른 커뮤니티 및 다른 프로그래밍 언어는 코드 형식에 대한 관점이 다릅니다. 예를 들어 Go 에는 하나의 코드 서식 스타일 만 있지만 C 또는 C ++에는 많은 코드 형식이 있습니다.

나는 그것이 나쁜 생각이라고 생각합니다. 많은 답변은 이미 누가 실제로 라인을 추가 했는지 파악하기가 어려워 져 역사를 더럽 히고 사람들이 무엇이든 커밋하고 포맷 봇이 처리하도록 장려 한다는 점을 이미 다루었 습니다.

더 나은 방법은 형식 검사기를 빌드 도구에 통합하는 것입니다. (Java에는 Checkstyle이 있습니다 ) 그런 다음 빌드가 통과하면 (포맷 포함) 사람들이 브랜치를 메인 브랜치로 병합 할 수 있습니다.

사람들이 메인 브랜치에 직접 커밋하도록 허용하는 경우 (예를 들어 Subversion과 같이) 모든 사람이 형식화 된 코드 만 커밋하는 규칙을 갖도록해야합니다 (또는 일부 검사가 실행 된 후 서버가 커밋 만 수락하도록해야 함). ).

일반적으로 나는 그것이 나쁜 생각이라고 생각합니다. 원칙적으로 이것은 유효한 아이디어이지만 실제로 문제가 될 수 있습니다. 코드 포맷터가 코드를 손상시키는 것은 실제로 가능한 일이며, 개발자가 적의에 반응하도록하기 위해 한 번의 포맷 만 실행하면됩니다 (예 : "귀찮은 코드 포맷터가 빌드를 중단했습니다. 지금 끄십시오 ! " ).

@BasileStarynkevitch의 권고와 같은 맥락에서, 우리는 git 서버 측 post-receive 훅을 사용하여 코드 스타일에 대한 "보조 이메일"을 보냅니다.

스타일 위반이 포함 된 커밋을 푸시하면 git origin 서버는 스타일 지침을 위반했음을 알리는 코드를 이메일로 보내 코드를 수정 하도록 권장 합니다. 그러나 하우스 스타일을 깨는 데 유효한 이유가있을 수 있으므로 (예 : 줄 길이 제한을 초과하는 긴 문자열)이를 적용하지 않습니다.

코드베이스에 해를 끼치는 체계적인 문제라면 코드 검토에서 코드 스타일 문제를 제기해야 할 때입니다. 잘못된 코드 스타일은 버그를 가려서 코드를 읽기 어렵게 만들 수 있으므로 유효한 코드 검토 문제가 될 수 있습니다.

사물의 "사회적 문제"측면에 추가하기 위해, 사람들이 발견 한 미용 적 및 문체 적 결함을 고치도록 장려 할 가치가 있습니다. 표준 커밋 메시지 "Cosmetic"이 있습니다. 다른 개발자가 알고있는 코드 스타일 수정에는 주요 변경 사항이 포함되어 있지 않습니다.

@DocBrown이 말했듯이 다른 옵션은 IDE 내에서 코드 스타일을 적용하는 것입니다. CodeMaid 를 Visual Studio와 함께 사용 하여 많은 일반적인 스타일 오류를 수정합니다. 그것은 코드 파일을 저장할 때 실행됩니다. 즉, 나쁜 스타일의 코드는 이론 상으로는 그것을 저장소로 만들면 안됩니다 :-).

그렇습니다, 나는 그것이 나쁜 생각이라고 생각합니다. 나를 잘못 생각하지 마십시오. 그 이유는 훌륭하게 들리지만 결과는 여전히 끔찍할 수 있습니다.

추적 된 분기를 가져올 때 병합 충돌이 발생하지만 적어도 그럴 것이라고 두려워하지만 잘못 될 수 있습니다.

직장에서 지금 테스트하고 싶지는 않지만 직접 시험해보십시오.

실제로 최근 커밋을 확인할 수 있습니다. 새로운 지점을 만들고, 사소한 일, 체리 픽을 선택하거나 자동 커밋없이 병합하십시오.

그런 다음 스크립트를 실행하고 당기고 결과가 끔찍한 병합 혼란이라면 낮에는 분명히하지 마십시오.

대신 야간 빌드 또는 매주 빌드에 넣을 수 있습니다.

그러나 야간에도 나쁜 생각 일 수 있습니다.

모든 것이 월요일에 끝났기 때문에 병합 충돌이 발생하지 않을 것이라고 확신 할 때 매주 실행할 수 있습니다.

그렇지 않으면 휴가철에 병합 충돌이 발생하지 않는 연중 1-2 회 실행하십시오.

그러나 솔루션은 코드 스타일의 우선 순위에 따라 달라질 수 있습니다.

git 저장소를 자동으로 만들고 프로젝트의 후크를 설정하는 설정 스크립트를 만드는 것이 더 좋을 것이라고 생각합니다.

또는 프로젝트 내 개발자의 폴더에 후크 설정 스크립트를 포함시키고 간단히 git 자체로 체크인 할 수 있습니다.

내가 언급하지 않은 것은 때때로 규칙 세트에 따라 무언가를 형식화하지 않는 정당한 이유가 있다는 사실입니다. 때로는 99 %의 시간이 적절한 지침에 따라 코드의 선명도가 향상됩니다. 인간은 그 전화를해야합니다. 이러한 경우 자동 코드 형식화로 인해 읽기가 어려워집니다.

끔찍한 생각입니다.

개발자 동료 중 한 명이 소스 파일을 약간 변경 한 경우 코드 검토를 통과하지 못합니다. 그것은 단지 모든 사람의 삶을 어렵게 만듭니다. 변경이 필요한 코드를 변경하십시오. 무의미한 변경으로 인해 병합 충돌이 발생하여 오류가 발생할 수 있으며 무의미한 작업을 만들 수 있습니다.

이 작업을 정기적으로 수행하려면 끔찍합니다.

그리고 코드 포매터가 어떤 종류의 변경을했는지에 대한 의문이 있습니다. 편집기에서 자동 서식을 사용하면 합리적으로 작동하며 자동 서식이 완벽하지 않을 때 개선 할 수 있습니다. 그것을 넘어서는 코드 포매터를 사용하면 코드를 개선하지 않고 코드를 악화시킬 수 있습니다.

그리고 사회적 문제가 있습니다. 모든 사람들이 자신의 코드 스타일을 사용하도록 강요하려는 사람들이 있으며 더 유연한 사람들이 있습니다. 이런 식으로 다른 사람들에게 자신의 스타일을 강요하고자하는 "grammer-nazi"(맞춤법 의도적 인) 유형의 개발자가 제안했을 것입니다. 반발을 예상하고 유연하고 일반적으로 쉽게 진행할 수있는 개발자가 발을 내딛을 것으로 기대하십시오.

사용하는 VCS는 언급하지 않았지만 다른 옵션에 따라 서버 측 후크가 있습니다. git과 같은 VCS가이를 지원합니다. 푸시되는 버전에서 포맷터를 실행하는 서버 측 후크를 설치 한 다음 포맷 된 파일을 푸시중인 버전과 비교할 수 있습니다. 서로 다른 경우 개발자가 올바른 형식을 사용하지 않아 서버가 푸시를 거부 할 수 있습니다. 이렇게하면 개발자는 원하는 형식으로 만 코드를 푸시하여 처음부터 깨끗한 코드를 작성하도록해야합니다. 따라서 개발자는 올바른 형식의 코드를 테스트하고 개발자가 클라이언트 쪽을 수동으로 설치하지 않아도됩니다. 훅.

더 깨끗한 코드 형식과 더 정확하고 이해하기 쉬운 git history 간의 절충점입니다. 프로젝트의 성격과 git history 또는 얼마나 자주 진행되고 있는지 이해하기 위해 비난을 받는가에 달려 있습니다. 새로운 작업을 수행하고 이전 버전과의 호환성을 유지할 필요가없는 경우 일반적으로 기록은 중요한 역할을하지 않습니다.

이 아이디어는 다른 답변과 비슷하지만 내 제안에 대해서는 언급 할 수 없습니다.

한 가지 옵션은 커밋 기능에 대한 별칭 (또는 후크 등)을 설정하여 커밋되기 전에 커밋 할 코드에서 코드 포맷터를 실행하는 것입니다.

결과는 2 개 이상일 수 있습니다.

1) 사용자에게 제안 된 변경 사항을 표시하고 변경 사항을 적용하고 커미트하도록 승인을 요청하십시오.

2) 제안 된 변경 사항을 무시하고 원래 코드를 커밋하십시오.

옵션 1에서 제안한 변경 사항을 편집하는 기능과 같이 이러한 옵션에 유연성을 추가 할 수도 있습니다. 이러한 코딩 표준을 얼마나 강하게 적용하고 싶은가에 따라 다른 아이디어는 시스템에서 옵션 2가 선택되었습니다.

이는 원하는대로 모든 코드를 자동으로 확인하는 균형을 유지하면서 개발자의 요구에 맞게 유연성을 유지할 수 있습니다. 또한 다른 답변에서 언급했듯이 형식 차이가있는 코드를 '자동 거부'하지 않을 수도 있습니다. '자동 서식 수정을 검토하고 승인했습니다. commit '옵션을 사용하면 각 개발자의 작업에 대한 개인 책임을 유지하며 VCS를 망칠 수 없습니다.

나는 저장소에서 그것을하지 않을 것이지만 도구가 그것을 지원한다면 저장 할 것입니다. Eclipse는 하나이며 정렬을 포함하여 코드 정리를 수행합니다.

좋은 부분은 프로젝트의 일부이므로 모든 개발자가 프로젝트에 사용할 수 있다는 것입니다.

추가 보너스 합병은 상황이 바뀌지 않기 때문에 크게 단순화됩니다.

코드 검토는 잘못된 코드를 방지합니다.

내가 할 다른 곳은 빌드의 일부입니다. 필자의 경우 maven 빌드가 XML을 다시 포맷하고 pom 파일을 정리하고 코드를 다시 포맷하도록합니다.

그렇게하면 개발자가 푸시 할 준비가되면 풀 요청을 위해 정리됩니다.