모듈을 수정 / 추가하는 동안 다른 개발자 코드를 다시 포맷해도 괜찮습니까?

그룹 분위기에서 개발하고 일부 코드 기반에서 기능을 추가하거나 수정하는 동안. 이전 개발자 코드를 현재 코딩 표준에 맞게 다시 포맷하는 것이 불쾌하거나 무례한 것으로 간주됩니까? 표준이 변경되었으며 앞으로도 계속 변경 될 것임을 알고 있지만 누군가 코드 형식을 변경하여 변경하면 다른 사람이 기분을 상하게 할 수 있습니까?

분명히하기 위해 나는 탭과 공백 등을 엉망으로 만드는 논리를 변경하는 것에 대해 이야기하지 않습니다.

편집 : 코딩 표준을 위해이 작업을 수행 할뿐만 아니라 코드를 읽고 최신 상태로 유지하는 데 도움이되므로 중요한 응용 프로그램을 수정하기 전에 구현 된 논리를 완전히 이해할 수 있습니다.

표준이 합의 된 한 이것이 정상이라고 생각합니다. 그러나주의 사항 다른 사용자가 동시에 파일을 수정하고있을 가능성이 있는지 확인하십시오. 서식을 변경했기 때문에 병합을 더 어렵게 만들면별로 인기가 없습니다.

예, 코드는 프로젝트에 속해 있어야합니다. 코드를 표준으로 올리면 프로젝트의 기술 적자를 줄일 수 있습니다. 수정하는 경우 현재 책임이 있습니다. 이전 코드의 경우 원래 개발자가 더 이상 프로젝트에 없거나 새로운 임무를 수행 할 수 있습니다.

이런 종류의 변경 작업을 수행 할 때는 다시 포맷 한 후 확인 테스트를 실행하는 것이 좋습니다. 그들이 통과하면 기능 변경을 수행하기 전에 코드를 확인하십시오.

편집 :이 질문의 맥락에서 표준으로 다시 포맷하는 것이 적절합니다. 표준이 없으면 표준을지지하고 형식에 대한 표준이있을 때까지 다시 포맷하지 않는 것이 좋습니다. 프로젝트에 속하는 코드를 사용하여 개인 취향 / 표준으로 다시 포맷해서는 안됩니다.

특정 파일을 수정 / 추가 할 때 코드를 리팩터링하는 것이 항상 좋은 습관 이라고 생각 합니다. 여기에는 변수 / 방법 및 코딩 스타일에 대한 적절한 명명 규칙을 반영하도록 코드 스타일을 업데이트하는 것이 포함됩니다.

나는 항상 이것을한다. 이전 코드는 동일한 표준의 새 코드로 유지되어야하며 작업하는 동안 코드를 수정하지 않으면 아무도 할 수 없습니다. 보이 스카우트 규칙에 해당한다고 생각합니다.

이것이 좋은 습관이고 코드 유지 관리에 필요한 부분이라고 생각합니다.

버전 제어 시스템에 대한 한 커밋의 형식 변경 사항과 별도의 커밋의 기능 변경 사항을 확인하여 자신과 다른 사람이 발생한 내용을 이해하는 것이 좋습니다.

변경 사항이 "종교적"이 아닌 한 문제가 없을 것입니다. 모든 수업을 거치지 말고 중괄호를 메소드의 첫 번째 줄로 옮기십시오. 형식이 합법적 인 "다른 사람들에 대한 다른 스트로크"유형 인 경우 누군가가 들어 와서 가장 자주 편집하는 코드에 형식을 적용 할 때 약간 성가시다. 그러나 해당 모듈의 기본 편집기가되면 서식 변경 내용을 적절하게 적용하십시오.

예. 적합하다고 생각되는대로 코드를 "수정"하십시오. 실용 프로그래머가 자신의 저서 The Pragmatic Programmer 에서 말하는 것처럼 깨진 창은 없습니다. 코드가 파에 맞지 않으면 깨진 창으로 간주됩니다.

체크인시 자동으로 재 포맷을 수행하는 다양한 리포지토리와 소스를 가져 오는 플랫폼에 따라 CR / LF 페어링 변경과 같은 작은 것들이 있습니다.

델타 체크인은 많은 형식의 재 포맷으로 인해 혼란스러워지고 회귀 문제가있는 경우 문제가되는 코드 블록을 찾기가 더 어려워진다는 점에서 자체 재구성을 수행하는 데 큰 단점이 있습니다.

코드베이스가 오래되었으므로 한 번에 코드 표준을 콜드에서 가져 와서 현재 표준으로 다시 포맷해야 코드의 미래를 밝게 할 수 있습니다.

순전히 "포맷"문제에 대해 이야기하고 있기 때문에 (버그를 수정하지 않고 자신의 표준에 맞게 보이게한다는 의미), 원래 사람이 여전히 코드를 유지하고 있는지 여부에 달려 있다고 생각합니다.

제작자가 여전히 프로젝트를 진행하고 있다면 무례합니다. 당신에게 "보일"것은 그들에게 "보일 것"이 아니며 포맷을 위해 코드를 수정하는 것은 공손하지 않습니다. 또한 많은 시간을 낭비 할 수 있습니다.

나는 매우 소유주의 개발자와 한 번 프로젝트를 진행하고있었습니다. 수년에 걸쳐, 나는 코드가 읽기 쉽고, 암시 적 실수가 적고, 자기 문서화가 쉽다고 느끼는 매우 체계적인 방법으로 코드를 개발했습니다. 반면에이 사람은 300 자 너비의 긴 줄이있는 모든 암시 적 기능을 사용하는 편이 좋았으므로 줄 수는 가독성보다 더 중요하다고 생각했기 때문에 30 인치 모니터를 사용해야했습니다. 내 코드를 통해 자신의 "선호 표준"으로 변경하는 중입니다 ... 여전히 병렬로 개발 중입니다! 다음날 아침 그의 혼란에 맞춰 2 일 분량의 작업을 찾았습니다.

이제 개발자가 사라지고 "더 나은 스타일"이 있다면 그것을 선택하십시오.

IDE에서 코드를 작성할 수 있으면 항상 자동 서식을 지정 하십시오.

• 수동 형식 변경으로 인해 버전 기록이 복잡해지지 않도록 방지
• 포맷터 프로파일은 모든 개발자들 사이에서 합의되어야합니다 (기본값을 선택 하시겠습니까?-)
• 파일 저장시 형식화 코드 및 가져 오기 구성 습관

예를 들어 이클립스에서는 먼저 포맷터를 실행하고 전체 코드베이스에 대한 가져 오기를 구성 할 수 있습니다. 그런 다음 저장하기 전에 ctrl + alt + f를 기억하십시오.