흔적s

항목

원인

회피방법

사용여부

비고

JavadocPackage

모든 method, class에는 help가 존재해야지 된다.

시간상 힘들고, 관리되지 않는 주석은 더욱 큰 혼란을 가지고 온다. method의 이름 규칙으로 대신하기로 한다.

X

NewlineAtEndOfFile

java code의 가장 마지막 줄은 빈공백열로 마쳐져야지 된다.

마지막 line에는 항시 빈공백을 넣는다.

O

Translation

Properties file을 이용한 경우, 국가별 번역이 모두 존재해야지 된다.

국가별 번역 파일을 따로 만들거나 default 문자열만을 이용한다.

O

FileLength

java file의 length는 2000 line을 넘지 않도록 작성한다.

2000 line이 넘어가는 경우, 설계상의 문제가 있기 때문에 class를 재정의한다.

O

FileTabCharacter

java file 내부에 tab 문자열이 있으면 안된다.

tab을 모두 space로 치환해서 사용하도록 한다.

O

RegexpSingleline

1 line에는 한개의 method만이 존재해야지 된다.

1 line에 대한 설정을 명확하게 해서 사용하도록 한다.

O

ConstantName, LocalFinalVariableName, LocalVariableName, MemberName, MethodName, PackageName

상수, class, method, parameter, package에 대한 naming 규칙이 틀릴 경우 발생한다.

naming 규칙에 맞는 명명법을 사용한다.

O

AvoidStarImport

package안에 있는 모든 객체들을 import할때 발생한다.

package안에서 사용되는 객체만을 import 한다.

O

테스트 코드 작성시에는 예외로 한다.

UnusedImports

package안에 사용하지 않는 객체를 import하면 발생한다.

package안에 사용되지 않는 객체들은 import 하지 않는다.

O

테스트 코드 작성시에는 예외로 한다.

LineLength

Line의 길이가 80자가 넘는 경우 발생한다.

Line의 길이를 120자로 수정해서 사용한다.

O

80 -> 120

MethodLength

Method 길이는 150자가 넘는 경우 발생한다.

Method 길이를 150자 이내로 사용한다.

O

ParameterNumber

Method의 parameter는 7개가 넘지 않도록 한다.

Method안의 input parameter의 갯수를 제한한다.

O

ModifierOrder

Method의 앞에 붙는 order는 다음과 같은 순서를 갖는다. (public, abstract, static, final, transient, volatile, synchronized, native, strictfp)

위 순서를 따르도록 한다.

O

AvoidNestedBlocks

내부 {}을 사용하지 않는다. - switch 구문 제외

내부 {}를 사용하지 않는다.

O

EmptyBlock

{}안에 아무런 구문이 없는 경우에 발생한다.

{}안에 구문이 없는 경우, 제거한다.

O

LeftCurly

'{'는 interface와 method의 구현문 끝에 넣어준다.

이집트 표기법을 사용하도록 한다.

O

NeedBraces

code안의 {}는 반드시 짝이 맞아야지 된다.

Compile error가 발생하지 않도록 만들어준다.

O

RightCurly

'}'의 뒤에는 반드시 CRLF만이 존재해야지 된다.

이집트 표기법을 사용하도록 한다.

O

AvoidInlineConditionals

1 line에서 if 문을 이용해서 처리하지 않는다.

이 condition은 제거하도록 한다.

X

1 line에서 가독성이 더 높은 경우가 존재한다.

EmptyStatement

for loop문에서 무한 loop를 발생시킬 수 있는 empty statement가 존재한다.

반드시 for loop의 경우에는 statement를 존재한다. loop문 안에서 조건이 걸리는 경우, while문을 사용하도록 한다.

O

EqualsHashCode

equals(), hashCode() 어느하나 override 된 경우, 둘다 재정의 되어야지 된다.

반드시 두 method를 쌍으로 재정의 하도록 한다.

O

IllegalInstantiation

boolean, String과 같이 java 기본 type을 재정의하는 경우 발생

java 기본 type은 그대로 사용하도록 한다.

O

InnerAssignment

if문이나 toString()과 같은 내부에서 변수에 값을 할당한다.

값의 할당은 따로 line을 잡아서 사용하도록 한다.

O

MagicNumber

상수값을 사용하는 경우 발생한다.

상수값을 static final로 이름을 지정해서 사용한다.

O

MissingSwitchDefault

switch 문에 default case가 없는 경우에 발생한다.

switch문은 반드시 default case를 넣어서 작성한다.

O

RedundantThrows

try-catch 시에 throws의 순서로 인하여 실행될 수 없는 catch문이 존재한다.

catch를 만들때, exception의 상속 상태를 확인하고 구성하도록 한다.

O

SimplifyBooleanExpression

if문내에서 1 line으로 return한다.

if 문안에서 return을 하지 않고, return값에 대한 명명을 정확히 한다.

O

SimplifyBooleanReturn

if문의 결과를 그대로 return 한다.

if문의 로직 자체를 return 값으로 변경한다.

O

DesignForExtension

객체는 확장 가능하도록 되어야지 되고, public문은 반드시 final로 재정의 되는 것을 막아줘야지 된다.

spring을 사용하는 경우 Proxy나 aspectJ에 의해서 재정의 되는 method는 다음 규칙에서 에러를 발생시킬 수 있기 때문에 사용하지 않는다.

X

FinalClass

final class의 생성자가 private로 되어있는 경우 발생한다.

final class의 경우에는 특별한 경우를 제외하고 사용하지 않는다.

O

spring을 이용하는 경우에는 특히 사용할 필요가 없는 구성이다.

HideUtilityClassConstructor

public static method만이 존재하는 class의 생성자가 protected, private로 되어 있다.

UtilityClass의 경우에는 모두 public modifier를 이용한다.

O

InterfaceIsType

interface가 type만이 존재하고, method가 존재하지 않는다.

type descript interface는 사용하지 않는다.

O

VisibilityModifier

getter/setter를 사용하지 않고, 내부 변수에 접근 가능하다.

getter/setter를 이용해서 property 처리를 하도록 한다.

O

ArrayTypeStyle

java style input array parameter를 이용한다. (java style : main(String[] args), C style : main(String args[])

java style을 사용하도록 한다.

O

FinalParameters

input parameter를 내부에서 참조만 하는 경우, final로 선언한다.

모든 input parameter는 final로 사용하는 것을 기본 원칙으로 갖는다.

O

coding style과 밀접한 연관이 있다.

TodoComment

"TODO: " 를 정확히 사용하지 않는 경우에 발생한다. (대소문자, 공백위치)

TODO를 정확히 사용한다.

O

UpperEll

'L', '1', 'I', 'i'를 명확히 구분할 수 있도록 method 이름과 객체이름을 짓는다.

명명규칙에 따라 이름을 작성하도록 한다.

O