VCS를 사용할 때 코드를 포맷하는 것이 나쁜 것입니까?

나는 코드가 올바르게 수행되도록하기 전에 거의 항상 코드를 포맷합니다. 우리 팀의 대부분은 실제로 코드를 신경 쓰지 않고 항상 코드를 올바르게 형식화하지는 않습니다 (코드에 영향을 미치지 않지만 유지하려고 할 때 가독성에 영향을 미치는 사소한 것들).

최근에 "저장시 포맷"옵션이있는 VS 전동 공구를 설치하고 이전에 포맷되지 않은 파일을 변경했습니다. 개발 VP가 나에게 와서 형식화를 요구했습니다. 머지 툴에서 한두 줄이 아닌 거의 전체 파일이 변경된 것으로 나타났기 때문에 (내가 쉽게 수정 한 것을 정확하게 볼 수 없음) 나중에 저장시 형식을 비활성화하도록 지시했습니다. 나는 그 우려를 이해하지만 때로는 형식화되지 않은 코드를 정렬하는 것이 어려우며 IMO는 항상 올바르게 형식화되어야합니다. 나는 변덕스러운 것들을 다시 포맷하는 것이 아니라 코드를 작성할 때 전동 공구를 사용하거나 텍스트를 쉽게 읽을 수 있도록 텍스트를 형식화하기 위해 키 명령을 사용할 것입니다 .SVN에서는 다음과 같이 나타납니다. 수정.

그래서 물어보십시오. 항상 코드를 실제로 형식화하는 것은 나쁜 것입니까? 코드를 읽을 수있게 만드는 것보다 그의 관심사가 더 유효합니까?

먼저, 팀은 서식 규칙을 선택하고이를 준수해야합니다. 당신은 계약에 와서 모든 사람이 그 계약에 충실하도록해야하므로 사람들이 어떻게 보일지에 대해 싸우지 않아도됩니다. 이것은 당신이 스스로하는 일이 아닙니다.

당신의 실제 질문에 관해서는. 코드 포맷은 나쁜 것이 아닙니다. 나쁜 점은 코드 변경과 동일한 커밋에서 주요 서식을 변경하는 것입니다. 팀이 일을 어떻게 구성해야하는지에 대한 합의에 이르면 코드를 통해 한 번만 통과하고 모든 것을 형식화하십시오. 그 자체로 확인하십시오. 커밋 메시지는 변경 사항이 단지 공백이며 작동하지 않음을 분명히합니다. 그런 다음 기능 변경이 필요할 때 다른 커밋을 수행하여 명확하게 볼 수 있습니다.

아니요, 서식 코드는 매우 중요 합니다. 그러나 커밋은 두 그룹으로 수행해야합니다.

1. 외관상의 변화 -코드를 더 읽기 쉽게 만드는 것.
2. 다른 변경 사항 -코드에 영향을 미치는 다른 모든 것.

커밋 메시지를 사용하여 화장품 만 변경되었음을 나타냅니다. 보다 실질적인 수정을 검색 할 때 쉽게 건너 뛸 수 있습니다.

둘 다 요점이 있지만 원하는 것을 얻을 수 있습니다. 먼저 코드를 포맷하고 해당 변경 사항 만 체크인하십시오. 다음으로 기능을 변경하고 두 번째 단계로 확인하십시오.

나도 형식 nit-picker이므로 몇 가지 팁이 있습니다.

• 첫 번째 필수 단계 : 탭 대 공백, 중괄호 위치, 주석 스타일 등과 같은 기본 형식 표준에 팀이 동의하도록하십시오. 이제 형식 변경이 모든 사람에게 완전히 놀라지 않을 것입니다. 발가락에.

• 변경 한 코드 주위에서만 서식을 정리하십시오. 하나의 기능 만 변경하면 해당 기능을 정리하십시오. 적어도 시간이 지남에 따라 더보기 좋은 코드가 생길 것입니다.

• 다른 코드 변경없이 별도의 커밋으로 주요 형식을 점검합니다. diff를 비교하는 것은 성 가실 수 있기 때문에 변경 후 코드를 변경하기 전에 코드를 비교할 가능성이 적은 경우에만 이러한 작업을 수행해야합니다. 나는 보통 그 코드를 개발하기 전에 가장 먼저 정리를한다.

• 중요한 변경 사항과 중요하지 않은 변경 사항을 언어에 따라 표시 할 수있는 좋은 diff 도구를 사용하십시오. 내가 가장 좋아하는 diff도 Beyond Compare 는 한 색상의 실제 코드 변경 사항과 다른 색상의 공백 / 주석 만 표시합니다.

팁 하나 더 편집 :

• 형식 언어마다 언어가 다르지만 코드를 실제로 변경하면 주요 정리 전후에 컴파일 된 바이너리를 비교하여 코드를 정리하지 않았는지 확인할 수 있습니다.

다음과 같은 경우가 아니면 다른 사람의 코드를 다시 포맷하고 변경 사항을 적용해서는 안됩니다.

• 팀 코딩 표준을 설정하려는 관리자입니다.
• 관리자가 팀 코딩 표준을 준수하도록 코드를 정리하도록 요청했습니다.
• 팀 코딩 표준을 준수하기 위해 더 이상 팀의 개발자가 아닌 코드를 정리하고 있습니다.

모든 경우에 팀 코딩 표준을 참조하는 것을 알 수 있습니다. 저는 팀의 합의 된 합의 된 코딩 표준을 강력하게 믿고 있습니다. 당신이 그들을 가지고 있다면, 원래 개발자는 돌아가서 팀 표준을 준수하기 위해 자신의 코드를 정리해야합니다. 표준이없는 경우 (그리고 반드시해야 할 경우), 특히 팀원의 철학을 따르기 위해 다른 팀원의 코드를 수정해서는 안됩니다. 귀하는 팀의 일원이며 코딩 표준이 중요하지만 팀 구성원 간의 신뢰와 존중도 중요합니다.