본 게시판 예제의 프로젝트를 선택하고 마우스 오른쪽 버튼을 눌러 Properties를 실행한다.
Checkstyle에서 "Checkstyle active for this project"를 체크하고 OK를 선택한다.
다음 그림과 같이 규칙에 어긋난 내용들이 나타나게 된다.
먼저 하단의 "Checkstyle violations" 뷰를 보면 프로젝트의 오류 리스트들이 종류별 정리되어 나타난다.
이 규칙은 위 그림에서 "Google Checks"을 선택했기 때문에 나오는 것으로 상세한 규칙은 구글 사이트나 번역 자료를 확인해 보길 바란다.
위 오류를 해결하는 방법은 2가지가 있다.
- 첫 번째 방법은 오류대로 수정하는 것이고,
- 두 번째 방법은 규칙을 수정하는 것이다.
규칙을 수정하는 이유는 현재 사용한 규칙이 구글의 방식이고
다소 타이트하게 구성되었기 때문에 각자에 맞게끔 수정해서 사용하는 것이 좋다.
개인적으로 예제로 사용된 구글 규칙은 Java 어플리케이션 규칙으로
웹일 경우는 다소 다르게 적용하는 게 좋을 것 같다.
Java 웹도 클래스 등을 사용하고 상속의 개념을 이용하지만 약하게 사용되고
특히 Spring은 클래스 개념이 조금 무시되기도 한다
(Spring은 다른 패키지 경로에 동일한 클래스가 있으면 오류 발생).
오류 수정을 위해
- 현재까지 진행된 보드(board1~4)를 수정하면 제공된 예제가 모두 정상이 되기에
board4를 복사해서 board41로 만든다.
SQL, JSP는 제외하고 Java 파일만 복사해서 수정해 본다.
- 규칙도 구글 원본을 수정하기 보다는 복사해서 별도의 규칙 파일을 만들어서 사용한다.
먼저, board4를 복사해서 board41로 만들고 클래스도 동일하게 바꾸어 준다.
다음으로 Eclipse의 windows > Preferences 메뉴를 실행한다.
Google Chceks를 선택하고 Copy 버튼을 눌러서 복사한다.
새로운 규칙 이름을 My Check로 입력하고 OK한다.
다음으로 프로젝트(board)를 선택하고 마우스 오른쪽 메뉴를 눌러서 컨텍스트 메뉴를 실행한다.
메뉴에서 Properties를 실행한후 왼쪽 트리에서 Checkstyle을 선택한다.
화면 중앙의 콤보 박스(Simple)에서 My Checks를 선택하고 OK 한다.
위 그림에서 오른쪽에 있는 Configure 버튼을 기억해야 한다.
Checkstyle violations 뷰에서 Marker count 컬럼명을 클릭하여 오류가 많은 순으로 정렬한다.
오류의 수는 진행 상태에 따라 개수가 바뀔 수 있다.
1. Line contains a tab character가 557회 발생했다.
탭(Tab) 키 사용을 금지하는 것으로 리스트에서 해당 항목을 더블 클릭한다.
831개의 오류가 난 파일들이 나오게 된다.
확인을 위해 앞서 만든 board41Ctr.java를 찾아서 다시 더블 클릭하면 다음 그림과 같은 화면이 나온다 (아무 파일을 해도 상관없다).
소스 코드 앞에 돋보기에 마우스를 대면 오류를 확인할 수 있다.
Eclipse의 바꾸기(Repalce)를 이용하여 탭을 공백(Space) 4개로 바꾸어 주면 돋보기들이 사라진다.
board41Svc 도 같은 방식으로 수정해 준다.
남는 돋보기는 다른 오류이니 넘어가도 된다.
앞서 오류가 난 39라인의 돋보기를 보면 오류명이 바뀌어 있다.
Checkstyle violations 뷰에서 board41Ctr.java 파일이 사라지고 없다.
탭키는 자주 사용되는 것으로 탭키를 누르면 공백으로 바꾸어 주는 것이 좋다.
구글에서 "eclipse tab to space"로 검색해서 방법을 익혀두면 좋을 것이다.
2. ‘X’ have incorrect indentation level X, expected level should be X가 467회 발생했다.
더블 클릭해서 상세 정보를 보면 들여쓰기 오류인 것을 알수 있다.
2번째(Level 2)에 있어야 하는데 4번째(Level 4)에 있다는 의미로 게시판 예제는 4개씩 들여썻고,
구글은 2칸씩 들여쓰기하고 있다.
프로젝트(board)를 선택하고 마우스 오른쪽 메뉴를 눌러서 컨텍스트 메뉴를 실행한다.
Properties > Checkstyle를 선택하고 Configure 버튼을 클릭하여 다음 화면을 실행한다.
왼쪽 트리에서 Miscellaneous를 선택하고 Indentation의 체크를 해제한뒤 OK 한다.
‘X’ have incorrect indentation level X, expected level should be X뿐 아니라
‘X’ child have incorrect indentation level X, expected level should be X (353회)도 사라지고 없다.
둘다 들여쓰기 규칙을 의미하는 것으로 위 설정으로 해당 규칙 적용이 되지 않아서 사라졌다.
3. Import statement for 'X' is in the wrong order. Should be in the 'X' group, expecting not assigned imports on this line. (65회)
이것은 Java의 import에 대한 규칙으로 구글 명명 규칙 번역 자료에 상세하게 나와 있다.
이 규칙도 다음 그림과 같이 Properties > Checkstyle | Configure > Import에서 "Custom Import Order"의 체그를 해제한다.
4. Missing a Javadoc comment가 29회 발생했다.
주석에 대한 것으로 현재는 //로 되어 있는 것을 그림과 같이 /* */로 작성해야 한다.
다만 지켜야 할 것이 시작시 /** 이고 문장은 반드시 점(.)으로 끝나야 한다.
이 주석들은 모아져 Javadoc(API 문서)으로 생성되는데 생성 방식은 구글링 해보길 바란다.
개인적으로 웹 프로그래밍에 Javadoc(API 문서)이 필요한 지와 사용여부에 의문이 있지만
주석은 꼭 필요한 것이라 함수의 파라메터에 대한 설명등 보다 많은 주석을 작성하는 것이 좋다.
5. Name 'X' must match pattern 'X'가 19회 발생했다.
상세 화면에서는 Type name 'board41Ctr' must match pattern '^[A-Z][a-zA-Z0-9]*$'.로 나온다.
이것은 정규식을 사용한 것으로 클래스명의 첫 글자를 대문자로 하라는 것이다.
board41Ctr, board41Src, boardVO를 Board41Ctr, Board41Src, BoardVO로 바꾸어 준다.
이것은 Java의 기본 명명 규칙으로 클래스명은 대문자로 시작하고
인스턴스는 소문자로 시작해서 둘을 구분짓는 것이다.
상 세 정보에서 이외에도Local variable name 'p' must match pattern '^[a-z][a-z0-9][a-zA-Z0-9]*$', Parameter name 'Filename' must match pattern '^[a-z][a-z0-9][a-zA-Z0-9]*$'. 가 있다.
해당 코드에서 돋보기를 보면 더 많은 오류가 동시에 발생하는데
이 오류는 변수명이 너무 짧고 파리메타의 변수명은 소문자로 시작해야 한다는 것이다.
board41Ctr, board41Src, boardVO만 수정하고 넘어간다.
다른 파일 코드를 수정하면 오류가 발생하기 때문에 전체적으로 수정해야 한다.
이것은 변수 이름에 대문자가 1개 이상이 사용되었다는 것이다.
Properties > Checkstyle | Configure 에서 "Naming Conventions"에 있는 "Abbreviation As Word In Name"의 체크를 해제해서
명명 규칙 적용을 해제한다.
7. 'X' should be separated from previous statement.가 13회 발생했다.
상세 정보를 보면 'METHOD_DEF' should be separated from previous statement와
',' should be separated from previous statement. 가 있다.
'METHOD_DEF' should be separated from previous statement은 앞 문장과 한 라인을 띄우라는 의미이다.
다음 그림의 27라인에서 엔터키를 치고 저장하면 돋보기가 사라진다.
',' should be separated from previous statement.는 콤마(,) 다음은 다음 라인에서 시작하라는 의미이다.
돋보기에 확인하면 Each variable declaration must be in its own statement라는 문장도 같이 나온다.
Checkstyle violations뷰에 Each variable declaration must be in its own statement는 5회 발생했다.
public class boardVO {
private String brdno, brdtitle, brdwriter, brdmemo, brddate, brdhit, brddeleteflag
, filecnt;
-----------------------------
public class boardVO {
private String brdno;
private String brdtitle;
private String brdwriter;
private String brdmemo;
private String brddate;
private String brdhit;
private String brddeleteflag;
private String filecnt;
개인적으로 오류가 난 코드를 선호하여 명명 규칙을 제거할 수도 있는데
위 코드로 수정하였다.
개인적인 코드 작성 원칙이 가급적 많은 코드를 한 화면에서 본다는 것이다.
많은 코드가 한 눈에 보여야 앞뒤 흐름를 파악하여 실제 버그를 빠르고 쉽게 해결한 경험때문이다.
더우기 같은 코드인데 앞뒤 순서에 따라 성능 향상등의 이점을 얻기도 하기 때문이다.
하지만 수정된 코드가 원칙처럼 사용되고 변수 선언 뒤에 //로 해당 변수의 설명을 넣는 것이 좋은 코드 방법이다.
개인적으로는 위 VO의 변수명, 테이블 필드명등의 이름을 동일하게 부여한다.
직관적으로 이해하게 하여 이러한 설명을 빼고 작성한다.
8. 'X' is not preceded with whitespace가 13회 발생했다.
더블 클릭해서 상세화면을 실행한다.
다음 그림과 같이 board41Ctr.java를 찾아서 다시 더블 클릭하면 오류가 발생한 코드를 볼 수 있다.
상세 메세지와 코드로 != 앞뒤로 공백이 없는 것을 확인할 수 있다.
공백을 넣어 주면 오류가 사라진다.
10회 발생한 'X' is not followed by whitespace도 같은 오류라 위 오류 수정에 의해 해제 되기도 한다.
안 될 경우 상세화면에서 해당 코드를 찾아서 공백 처리하면 된다.
아래 코드와 같이 블럭으로 {}를 넣어 주면 된다.
sqlSession.insert("insertBoard4", param);
else sqlSession.update("updateBoard4", param);
if (param.getBrdno() == null || "".equals(param.getBrdno())) {
sqlSession.insert("insertBoard4", param);
} else {
sqlSession.update("updateBoard4", param);
}
10. Line is longer than X characters (found X) 가 3회 발견되었다.
한 행의 코드 수가 100자를 넘겼다는 의미이다.
다음 그림과 같이 Maximum Line Length를 해제한다.
11. First sentence of Javadoc is incomplete (period is missing) or not present이 3회 발생했다.
이것은 Javadoc에서 언급한 것으로 문장을 마침표(.)로 끝내라는 것이다.
2가지가 더 있지만 모두 앞서 언급한 것과 같이 처리하면 된다.
board41Ctr.java, board41Src.java, boardVO.java의 코드를 보면 돋보기가 모두 사라진 것을 확인 할 수 있다.
board41Src.java에 노랗게 경고 표시가 되어 있는 것이 있다.
이 것은 HashMap의 세부 타일을 표시하면 좋다는 것으로 다음과 같이 수정하면
코드 편집창에 나타난 경고들이 모두 사라진다.
HashMap fparam = new HashMap();
fparam.put("fileno", fileno);
HashMap<String, String[]> fparam = new HashMap<String, String[]>();
이상으로 명명 규칙등과 관련된 Checkstyle 사용을 살펴 봤다.
이 외에도 더 많은 규칙이 있고 추가도 할 수 있다.
각자에 맞추어 선택하면 될 것이다.
'Java > 게시판 기타: 품질 등' 카테고리의 다른 글
| 5. PMD와 예외처리(Exception) (2) | 2016.05.07 |
|---|---|
| 1. 프로그램 작성 외의 것들 (1) | 2016.04.24 |
| 2. CheckStyle I - 설치 (0) | 2016.04.23 |
| 4. FindBugs (0) | 2016.04.23 |
