CheckStyle Rule 정의 목록

사내의 코드 품질 평가를 위해서 static analysis 방법을 조사하면서 항목에 대해서 list up을 할 필요성이 발견되어 조사한 내용들을 공유합니다. 

항목	원인	회피방법	사용여부	비고
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