IntelliJ IDEA: 코딩 스타일 및 코드 서식 지정

프로그래밍 언어는 음성 언어와 매우 유사합니다. 유일한 차이점은 우리가 원하는 것을 컴퓨터에 설명하기 위해 컴퓨터와의 통신을 용이하게 하는 것이 주된 목적인 특수 언어라는 것입니다. 하지만 컴퓨터와 개인적인 대화를 나눌 수는 없습니다. 프로그래밍 언어를 배우기 시작했을 때 책이나 CodeGym과 같은 교육 리소스를 살펴보았습니다. 그리고 이 리소스는 컴퓨터가 이해하는 코드를 보여주었습니다. 그러나 자바 언어에 대해 배우면서 당신도 그것을 이해해야 합니다. 모든 언어와 마찬가지로 일부 형식화 규칙이 프로그래밍에 채택되었습니다. 예를 들어, 예의 바른 사회에서 이렇게 쓰는 것은 나쁜 매너로 간주될 것입니다. 그리고 Java에서 대문자로 메소드 이름을 시작하는 것은 코딩 규칙을 심각하게 위반하는 것입니다. Java 코드에 대한 규칙은 Java 프로그래밍 언어에 대한 코드 규약 문서에 나와 있습니다 . 코딩 규칙은 들여쓰기와 같은 더 작은 세부 사항을 규제할 수도 있습니다. 들여쓰기가 일관되지 않고 어떤 사람은 탭을 사용하고 다른 사람은 공백을 사용하는 경우 버전 제어가 완전히 악몽이 될 것이라고 상상해 보십시오. 한 가지 방법으로 수정 사항을 체크인해야 하지만 공백과 탭의 차이로 인해 전체 파일이 변경된 것을 발견한 사람은 어떤 기분일까요? 물론 일반 언어와 마찬가지로 언어가 사용되는 위치에 따라 규칙이 변경될 수 있습니다. 예를 들어 웹의 방대한 영역에서 Google Java 스타일 가이드 와 Twitter Java 스타일 가이드를 찾을 수 있습니다.. 이 검토를 위해 테스트 대상이 필요합니다. 우리는 Gradle 빌드 자동화 시스템을 사용할 것입니다. 템플릿에서 새 프로젝트를 만들어 빠르게 시작할 수 있습니다. Gradle에는 훌륭한 플러그인이 있습니다: Build Init Plugin . 새 디렉터리로 이동하여 다음 명령을 실행해 보겠습니다. gradle init --type java-application 그런 다음 IntelliJ IDEA를 시작합니다. 열려 있는 프로젝트가 있는 창이 표시되면(즉, 코드 편집기와 프로젝트 트리가 표시됨) 를 사용하여 이 프로젝트를 닫습니다 File -> Close Project. 이제 시작 창에서 " Import Project"를 실행하고 새 프로젝트를 가져옵니다. 가져올 때 " Use autoimport" 체크박스를 설정합니다. 최첨단 개발 도구를 사용하여 어떻게든 삶을 단순화할 수 있는지 알아봅시다.

IDEA의 코드 서식 지정

프로젝트를 가져온 후 Ctrl+N을 누르고 클래스로 이동합니다 AppTest. 기본 테스트 클래스입니다. 다음과 같습니다.

 import org.junit.Test;
 import static org.junit.Assert.*;
 
 public class AppTest {
     @Test public void testAppHasAGreeting() {
         App classUnderTest = new App();
         assertNotNull("app should have a greeting", classUnderTest.getGreeting());
     }
 }

즉시 눈에 띄는 것은 무엇입니까? 메서드 선언과 같은 줄에 있는 주석, 보기 흉해 보이죠? 이 문제를 해결하는 방법? IntelliJ IDEA에는 Code다양한 코드 조작을 위한 " " 메뉴 항목이 있습니다. 이러한 조작 중 하나는 Reformat CodeCtrl+L을 사용하여 적용할 수 있는 " "입니다. 이렇게 하면 주석이 한 줄에 있고 메서드 선언이 다른 줄에 있습니다. 이 작업이 현재 선택된 코드에서 수행된다는 점에 바로 주목할 가치가 있습니다 . 선택 항목이 없으면 모든 항목에 대해 포맷 작업이 수행됩니다. 이제 새 테스트 방법을 추가해 보겠습니다.

 @Test
 public void testSumOfOddNumbers() {
 	List<Integer> data = Arrays.asList(1, 4, 2, 3, 6, 7, 9);
 	Integer result = data.stream().filter(number -> number % 2 == 0).reduce((n1, n2) -> n1 + n2).get();
 	assertThat(result, is(12));
 }

그리고 두 가지 가져오기:

import static org.hamcrest.CoreMatchers.is;
import static org.junit.Assert.assertThat;

보시다시피 Stream의 작업은 한 줄에 있습니다. 그러나 연결된 메서드 호출이 각 마침표 연산자에서 항상 새 줄로 분할되도록 하려면 어떻게 해야 할까요? 수동으로 할 수 있습니다. 그러나 우리는 모든 것이 자동으로 일어나기를 원한다는 것을 기억하십시오. 사실, 우리는 때때로 수동 단계를 잊어버리고 모든 곳에서 다른 형식으로 끝나게 될 것입니다. 그것은 좋지 않습니다. 따라서 IDEA가 형식화에 사용하는 규칙을 편집해야 합니다. 선택하다File -> SettingsIDEA 메뉴에서(또는 Ctrl+Alt+S 누르기). 설정 창의 검색 필드에 "코드 스타일"을 입력합니다. "코드 스타일" 섹션에서 Java 이외의 언어에 대한 설정을 지정할 수 있습니다. 그러나 Java는 지금 우리가 관심을 갖고 있는 것입니다. 보시다시피 설정은 여러 탭으로 나뉩니다. 매우 유용한 기능은 작업의 예가 창의 오른쪽 부분에 표시된다는 것입니다. 스크린샷은 "연결된 메서드 호출"을 "항상 래핑"으로 설정할 수 있음을 보여줍니다. 즉, 연결된 메서드 호출을 항상 별도의 줄로 분할합니다. 이제 테스트 클래스에서 서식 지정 버튼을 다시 클릭하면 실제로 작동하는 것을 볼 수 있습니다! 그러나 때로는 표준 서식 지정 규칙을 벗어나는 일부 코드의 서식을 지정해야 합니다. 다음과 같이 서식을 설정합니다. 서식을 방지하려면 "코드 스타일" 섹션에서 서식 지정 마커를 활성화합니다. 이제 코드가 다시 서식이 지정되지 않도록 테스트 클래스를 변경할 수 있습니다.

 @Test
 public void testSumOfOddNumbers() {
 	List<Integer> data = Arrays.asList(1, 4, 2, 3, 6, 7, 9);
 	// @formatter:off
 	Integer result = data.stream().filter(number -> number % 2 == 0)
                              .reduce((n1, n2) -> n1 + n2)
                              .get();
 	assertThat(result, is(12));
 	// @formatter:on
 }

Tab 키를 누르면 IDEA가 이를 공백으로 해석합니다(기본 동작임). Code Style그러나 " " 섹션 에서 이를 변경할 수 있습니다 . 보시다시피 많은 설정이 있습니다. Code style" " 설정에 대한 자세한 내용은 " IDEA 도움말: 코드 스타일 "에서 확인할 수 있습니다 . 또 다른 중요한 서식 기능이 있습니다. 가져오기 서식 지정입니다. 이 작업은 별도로 실행되며 " Optimize Imports"라고 합니다. Code -> Optimize Imports(Ctrl+Alt+O) 아래에 있습니다 . 가져오기 최적화는 Java에 대한 " Imports" 설정의 " " 탭 에 있는 설정에 따라 불필요한 가져오기를 제거하고 올바른 순서로 가져오기를 정렬합니다 . Code Style또한 이 서식이 자동으로 적용되도록 하려면 다음과 같은 좋은 소식이 있습니다.작업 저장 플러그인.

명령으로 설정 배포

위에서 서식 스타일을 원하는 대로 사용자 지정할 수 있음을 확인했습니다. 하지만 팀 내에서 이 스타일을 어떻게 사용합니까? 아주 쉽게. 몇 가지 옵션이 있습니다. 가장 간단한 방법은 코드 스타일 체계를 저장하는 것입니다. (또는 Ctrl+Alt+S를 눌러) 를 사용하여 IDEA 설정을 엽니다 File -> Settings. " Code Style" 섹션에서 "계획"을 볼 수 있습니다. 이것이 우리의 서식 체계입니다. 기본적으로 "기본" 체계가 사용되며 "IDE"라는 레이블이 지정됩니다. 즉, 이 설정은 IDE에만 적용되며 다른 사람에게는 영향을 미치지 않습니다. "사용자 지정" 체계를 만들려면 오른쪽에 있는 버튼을 사용하여 복사본을 만들고 이름을 지정합니다. 예를 들면 다음과 같습니다. CodeGym 그런 다음 설정을 가져오거나 내보낼 수 있습니다. 다른 옵션은 IDEA 설정을 가져오는 것입니다. 세 번째 옵션은 설정 저장소입니다. 설정 리포지토리를 사용하려면 다음 링크에서 IntelliJ IDEA 도움말 문서를 참조하십시오. 설정 리포지토리 ". 팀에서 통합 스타일을 추진하는 것에 대해 말하면서 Eclipse에서 스타일에 대한 좋은 지원을 언급하지 않을 수 없습니다. IDE. 이렇게 하려면 별도의 플러그인을 설치해야 합니다: 파일 -> 설정(Ctrl+Alt+S)을 통해 IDEA 설정을 열고 "플러그인" 섹션으로 이동합니다. 새 플러그인을 찾으려면 " " 버튼을 클릭합니다. 그런 Browse Repositories다음 검색 창에서 Eclipse Code Formatter 플러그인을 찾으십시오. 설치 후 IDEA를 다시 시작해야 합니다. 이것은 표준 절차입니다. 이제 모든 작업이 완료되었습니다. IDEA 설정에 "Eclipse Code Formatter"라는 새 섹션이 있습니다.. 다음과 같이 표시됩니다.

더 엄격한 요구 사항

IDEA 도구 외에도 빌드 자동화 플러그인을 사용하여 요구 사항을 강화할 수도 있습니다. 누군가가 올바른 형식을 사용했는지 수동으로 확인할 수 있는 방법이 없습니다. 5명이 한 팀이 될 수도 있습니다. 하지만 한 회사에 100명의 직원이 있으면 현실적이지 않습니다. 그리고 5개도 추적하기 어려울 것입니다. 그리고 왜 이것에 시간을 낭비합니까? 규칙을 위반하면 프로젝트가 구축되는 것을 방지하는 것이 훨씬 쉬울 것입니다. 사실 이것은 "코드 검사"라는 완전히 별개의 주제입니다. 이 기사에서는 작동 방식을 보여주고 싶습니다. 가장 인기 있는 Gradle 플러그인 중 하나(우리 프로젝트를 빌드하기 때문에 기억할 것입니다)는 pmd 입니다.. 활성화하려면 Gradle 프로젝트의 빌드 스크립트(프로젝트 루트에 있는 build.gradle 파일)로 이동하여 나머지 플러그인 옆에 pmd를 추가하세요.

 plugins {
     // Apply the java plugin to add support for Java
     id 'java'
     // Check source code
     id 'pmd'
     // Apply the application plugin to add support for building an application
     id 'application'
 }

이제 동일한 위치에 더 자세한 설정을 입력할 수 있습니다.

 pmd {
     ignoreFailures = false
     pmdTest.enabled = true
     ruleSets = [
             'java-basic',
             'java-braces',
             'java-clone',
             'java-codesize',
             'java-comments',
             'java-controversial',
             'java-coupling',
             'java-design',
             'java-empty',
             'java-finalizers',
             'java-imports',
             'java-optimizations',
             'java-strictexception',
             'java-strings',
             'java-typeresolution',
             'java-unnecessary',
             'java-unusedcode'
     ]
 }

이제 우리 프로젝트도 망가졌습니다. 실행 gradle build하면 오류가 발생합니다. 좋은 점은 빌드 중에 보고서가 생성된다는 것입니다. 오류가 있으면 다음과 같은 메시지가 표시됩니다.

 BUILD FAILED in 35s
 6 actionable tasks: 6 executed
 7 PMD rule violations were found. See the report at: file:///C:/_study/codestyle/build/reports/pmd/main.html

보고서로 이동하면 다음과 같은 내용이 표시됩니다. 또한 " Problem" 열은 pmd 플러그인 웹 사이트의 문제 설명에 대한 링크를 제공합니다. 예를 들어 " headerCommentRequirement Required" 오류의 경우 링크는 pmd — CommentRequired 로 이동합니다 . 이 오류는 클래스에 JavaDoc이 없다는 힌트입니다. 템플릿을 사용하여 클래스 위에 JavaDoc을 구성할 수 있습니다. 그리고 다음 내용을 지정합니다 File Header. 그런 다음 App 클래스 위에 있는 주석을 JavaDoc으로 바꾸고 새 빌드에서 오류가 사라진 것을 확인할 수 있습니다.

결론

코드 스타일은 프로젝트의 생산성을 극대화하는 데 중요합니다. 공유 규칙에 따라 작성된 아름다운 코드는 동료가 더 쉽고 빠르게 이해할 수 있도록 보장하고 많은 비판을 주지 않습니다. 최신 개발 도구를 사용하면 스타일 규칙을 고수하는 것이 그리 어렵지 않습니다. 이 검토가 이것이 사실임을 입증하기를 바랍니다. 전통에 따라 주제에 대한 약간의 추가 자료가 있습니다.

• JetBrainsTV의 비디오: " 코드 검사(IntelliJ IDEA) "
• " Gradle 플러그인을 사용한 코드 분석 " 검토
• " 코드 품질 자동화 " 과정