답변:
나는 이것을하는 것이 매우 중요 하다고 생각합니다 . 이유는 다음과 같습니다.
그렇게하면 모든 사람이 모든 코드를 체크인하는 것이 좋습니다. 한 사람이 전체 코드베이스를 다시 포맷 한 다음 모든 사람을 다시 체크인하여 서식을 설정하기위한 하나의 "거대한"변경 사항이 있습니다 (모두 무시 할 수 있음). 그 후 모든 diff는 실제 코드 diff입니다.
비트 단위로 수행하면 실제 코드 변경 사항과 서식 변경 내용이 혼합되어 변경 랜드에서 불필요하게 지저분해질 것입니다.
사람들이 장점을 추가하는 것처럼 보이므로 여기에 내 자신의 대답을 던질 것입니다. 내가 단점으로 보는 것은 :
간단히 말해서, 자동화되지 않은 규칙 세트는 최소 스타일 / 가독성 요구 사항을 설정하며, 여기서 자동화 된 규칙은 최소 및 최대를 설정합니다.
VB (버전 5)를보고 가장 성가신 점 중 하나를 찾는 것은 내 코드를 강제로 다시 포맷하고 기본 형식 이상으로 제거하는 것이 었습니다.
가장 중요한 단점은 사용자 지정 형식이 중요한 위치에서 손실되는 것입니다.
특정 조건 중 하나라도 존재하지만 충족되지 않은 경우 실패하는 전형적인 온 전성 검사 if ()를 상상해보십시오 ...
if(
(user.id == TEST_ID)
||(
(user.id == UserID)
&&(
( user.type == HUMAN_USER && user.name.size() >= MIN_NAME )
||( user.type == EMULATION && input.source != SOURCE_INTERNAL ))
&& ( user.email == NULL || emailValidator.isValid(user.email))
&& ( (user.phone == NULL) == (user.type == EMULATION) )
// several more lines like this.)
){ /* handle results */ }조건의 논리적 구조에 따라 적절한 들여 쓰기 덕분에 읽을 수 있습니다.
이제 자동화 된 툴은 서로 다른 조건을 관련 라인으로 논리적으로 분리 할 수있는 단서가 없습니다. 각 라인이 한 줄에 3-4 개의 조건이 모여서 다음 조건을 반으로 나눌 이유가 없습니다. 또는 줄당 하나의 비교 표현식으로 분할합니다. 화면에서 더 예쁘게 보일 수도 있지만 로직이 손실됩니다.
그것은 당신의 필요에 달려 있지만, 일부 금기 사항은 매우 도움이됩니다.
이 경우를 고려하십시오.
if( x == 0 )
return foo;
//do something else
return bar;if 케이스에 로깅을 추가하려면 실수로 쓸 수 있습니다.
if( x == 0 )
log.info("x was 0");
return foo;
//do something else
return bar;그리고 갑자기 메소드는 항상을 반환합니다 foo.
편집 : 자동 서식이 아니라 스타일을 확인합니다. 그 답변도 주제가 아닌 경우 죄송합니다. :)
내 경험상, 그것은 좋은 일입니다. 하나가 없으면 코드 비교는 종종 공백 형식의 혼란을 나타내며 실제 코드 변경을 숨길 수 있습니다. 내 경험상, 누군가의 서식을 엉망으로 만드는 것은 특히 팀 전체의 일관성에 따른 잠재적 이점으로 인해 만들어지는 죄가 아닙니다.