자동 형식을 사용하여 일식으로 코드를 형식화하는 것이 좋습니다


20

나는 코딩을 위해 이클립스를 사용하고 우리가 사용하는 언어는 Java입니다. 누군가가 자동 포맷터 (CTRL + SHIFT + F)를 사용하여 코드를 올바르게 포맷하도록 제안하면이 명령은 코드를 포맷하지만 때로는 전체적인 모양이 이상 해져 실제로 읽을 수없는 것으로 느껴집니다.

이것이 권장되는 일입니까? 그렇지 않다면 이클립스에서 코드를 포맷하는 것이 더 낫습니다.


나는 이맥스의 자동 포맷 용량 모든 시간을 사용 - 충돌에 대한 잠재력 (예 : SC 병합 포함)이 있습니다 ..하지만 전반적으로, 당신의 형식을 표준화하는 것이 매우 도움이된다
워렌

답변:


34

엄격한 코드 형식 규칙은 여러 개발자가 버전 제어 시스템을 사용하여 동일한 코드에서 작업 할 때 유용합니다. 다른 개발자가 동일한 코드가 병합 도구와 다르게 보일 수있는 다른 형식 규칙이있는 경우 병합이 어려울 수 있습니다.

Eclipse (또는 그 문제에 대한 좋은 IDE)에는 환경 설정 섹션 (Java> 코드 스타일> 포맷터)에서 사용자 정의 할 수있는 코드 형식 규칙이 있습니다. 가장 좋아하는 것을 선택하고 Java 표준 코드 규칙 도 살펴보십시오 . 많은 오픈 소스 프로젝트에는 Eclipse 포맷터로 시행 할 수있는 자체 코드 규칙이 있습니다.

또한 CodeStyle, PMD 및 Findbugs와 같은 표준 도구가 추가 규칙을 적용하고 일반적인 (낮은 수준의) 반 패턴 및 실수를 방지합니다.


4
포맷터를 원하는 방식으로 설정하면 "내보내기"버튼이있어 .xml 파일로 저장할 수 있습니다. 우리는 이것을 SVN 저장소에 넣었으므로 모든 사람들은 프로젝트를 체크 아웃 할 때 액세스 할 수 있습니다.
Chris

나는 이것에 동의하고 PMD와 FindBugs를 사용합니다. 그러나 팀의 모든 사람 이 코드 형식 규칙을 따르고 사용하는 경우에만 좋습니다 . 그렇지 않으면 일부 개발자가 아닌 다른 개발자가 변경 + 서식을 지정하는 커밋으로 끝나고 "실제"변경 사항을 확인하기가 어렵습니다. 즉, 이전 코드가 자동 포맷터로 아직 포맷되지 않은 경우 한 번의 커밋에서 추가 변경으로 포맷하지 마십시오.
Mufasa

2
코드 형식 설정을 사용자 정의하는 경우 해당 설정을 소스 개발자로 푸시하여 모든 개발자가 가져 오거나 모든 종류의 스타일에 동의 할 수 있도록 일종의 위키 또는 개발자 문서로 게시하십시오.
Mufasa

24

자동 포맷터가 매우 유용하다는 것을 알았습니다. 오류가 발생하기 쉽고 "인지 마찰"을 유발하는 코드의 형식을 결정하는 방법을 끊임없이 결정하는 대신 서식 규칙을 설정하고 Eclipse에서 코드를 형식화 할 수 있습니다 (이상적으로는 "작업 저장"사용) ). 물론이를 위해서는 일관된 형식의 코드 기반이 있거나 설정 한 규칙에 따라 코드를 다시 포맷해야합니다.

"자동 저장시 저장"을 사용하는 것은 증분 컴파일을 사용하는 것과 약간 비슷하므로 코드 형식 또는 구문과 같은 사소한 문제가 아닌 두뇌가 코드 자체에 계속 집중할 수 있습니다.

그러나 예, 때로는 자동 포맷터가 멋지게 포맷 된 테이블을 엉망으로 만듭니다. 그런 경우에는 "켜기 / 끄기 태그"를 사용합니다. 이들은 코드 형식화 프로파일의 "켜기 / 끄기 태그"탭에서 구성됩니다. 이를 사용하여 코드의 영역이 자동으로 포맷되지 않도록 제외 할 수 있습니다.

// @formatter:off

... my nicely formatted table here ...

// @formatter:on

5
+1 : 온 / 오프 태그에 대해 전혀 알지 못했거나 더 정확하게 말하지 않았습니다.
Paul Cager

1
저장시 자동 서식은 프로젝트의 모든 사람이 사용하는 경우 좋습니다. 일부 개발자 만 사용하는 경우 코드 서식 변경으로 동시에 변경 내용을 커밋하기가 너무 쉬워 커밋에서 "실제"변경 사항을 찾기가 어렵습니다.
Mufasa

@Mufasa 네, 맞습니다.
JesperE

1
등의 코멘트 : 포맷하지 않는 내 슈퍼 형식 * / 이클립스 - 당신이 형식의 코멘트를하지 않을 때 당신은 / *을 작성할 수 있습니다
DAWID 할 Drozd

5

추천 여부는 누구에게 물어 보느냐에 달려 있습니다.

나는 당신이 코드를 직접 포맷하는 것을 선호한다고 상상할 수 있습니다. 결국 가장 좋고 가장 읽기 쉬운 것을 알고 있습니다. 더해서, 당신이 사려 깊은 사람이라면 다른 사람도 더 읽기 쉽게 만들 수 있습니다.

기계에는 그러한 종류의 예측이 없으며 엄격한 규칙으로 형식을 지정하더라도 코드가 약간 혼란스럽게 보일 수 있습니다.

좋은 IDE 나 도구는 종종 코드를 포맷 할 때 반 정도의 작업을 수행 할 수 있지만 항상 가능한 한 읽기 쉬운 것은 아닙니다.

그래서 내 충고 : 다른 사람으로부터 코드를받지 않으면 사용하지 마십시오. 그렇지 않으면 읽을 수없는 혼란입니다.


5

모든 소스 파일에서 일관된 스타일을 사용하려면 항상 사용해야합니다. 또한 일반적으로 서식을 수동으로 조정하는 데 많은 시간을 절약 할 수 있습니다.

Eclipse의 Java 포맷터는 꽤 잘 작동하며 완전히 사용자 정의 할 수 있습니다. 기본 설정에 동의하지 않으면 (완전히 이해할 수있는) 포맷터를 자신의 개인 스타일 기본 설정이나 사용하는 표준에 맞게 조정해야합니다. Java / Code Style / Formatter의 환경 설정에서이를 수행 할 수 있습니다.

포맷터는 혼자 작업하지 않을 때 더욱 유용합니다. 귀하와 귀하의 팀원이 귀하가 완벽한 코드 스타일 ™이라고 생각하는 것에 동의하지 않을 가능성이 큽니다. 이 경우이 특정 코드 스타일링에 대한 공통 기반에 대해 한 번, 모든 형식 기 규칙에 동의해야합니다. 그런 다음 모두가 바로 가기 바로 가기를 칠 수 있고 모든 것이 합의 된 스타일에 맞습니다. 그렇게하면 개인적인 취향 (글을 쓸 때)이 방해가되지 않습니다. 그리고 포매터 스타일은 Eclipse의 프로젝트 파일에 저장 될 수 있으므로 각 프로젝트마다 다른 포매터도 가능합니다.


0

저장시 자동으로 코드 형식을 지정하는 것을 좋아하지만 실제로는 개인 프로젝트에서 코드를 활성화했습니다. Eclipse 포맷터에 권장하지 않는 몇 가지 중요한 버그가 있기 때문에 Eclipse 기반 제품을 사용하는 프로젝트 팀에서는이 방법을 완전히 권장 할 수 없습니다.

특히 "코드 정리"+ "포맷터"를 활성화 한 경우 저장 시마다 들여 쓰기가 수정 / 고정 해제됩니다.

Eclipse의 각 새 버전은 포맷터를 변경할 수 있지만 (더 나은) JavaDocs와 같은 중요한 변경 사항이 추가 공간을 결국 제거 *하지만 Helios 및 많은 기업이 이전 Rational Software 버전의 Eclipse를 사용한 후 언젠가 도입 된 경우 Helios를 기본으로 사용합니다.

Eclipse에서 제공하는 코드 포맷터는 해당 API에 따라 확장 가능하지 않습니다. 실제로 명시 적으로 CodeFormatter javadoc을 명시합니다

이 클래스는 클라이언트가 서브 클래스하기위한 것이 아닙니다.

물론, 아직 유효한 비상업적 대안을 찾지 못했습니다. Jalopy는 현재 몇 년 동안 업데이트되지 않았으며 github의 포크는 아직 권장하지 않습니다. 또한 Eclipse에 대한 업데이트 사이트가 통합되어 있지도 않습니다. 실제로 Jalopy를 사용하여 cleanpom-maven-plugin을했던 것처럼 코드 형식을 빌드의 일부로 만들려고했지만 Jalopy에 대한 업데이트가 부족하여 그 아이디어가 길가에 떨어졌습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.