AddEmptyString


우선순위 : 3

The conversion of literals to strings by concatenating them with empty strings is inefficient. It is much better to use one of the type-specific toString() methods instead.

 

문자열로 형변환을 할 때 빈 문자열로 + 연산을 하는 것은 비효율적이다.
이럴 경우에는 각 타입별로 구현된 toString() 메소드를 이용하는 것이
더 낫다.

 

샘플 코드



AvoidArrayLoops


우선순위 : 3

Instead of manually copying data between two arrays, use the efficient System.arraycopy method instead.

 

두 배열간에 복사를 할 때는 루프를 통해 수동적으로 하지 말고
System.arraycopy를 이용하는 것이 더 효율적이다.

 

샘플 코드

 

부연설명

 

System.arraycopy 사용법
System.arraycopy는 다음과 같은 5개의 인자를 받는다.

 

Object src : 복사할 원본 소스 배열
int srcPos : 소스에서 복사를 시작할 index
Object dest : 소스를 복사할 대상 배열
int destPos : 대상 배열에서 쓰기 시작할 index
int length : 원본에서 몇개의 요소를 읽어올지에 대한 길이

 

예제

결과

destStrArr1 : null
destStrArr1 : null
destStrArr1 : 요소1
destStrArr1 : 요소2
destStrArr1 : null

=======================================

destStrArr2 : 요소1
destStrArr2 : 요소2
destStrArr2 : 요소3
destStrArr2 : 요소4
destStrArr2 : 요소5




RedundantFieldInitializer


우선순위 : 3

Java will initialize fields with known default values so any explicit initialization of those same defaults is redundant and results in a larger class file (approximately three additional bytecode instructions per field).

 

자바의 멤버 변수들은 잘 알려진 값으로 자동 초기화 되므로 명시적으로 이러한
기본값으로 초기화 할 필요가 없으며 초기화할 경우 오히려 용량만 많이 차지하게 된다.

 

샘플 코드

 

부연 설명

아래 추가 샘플코드에 보면 FieldTest의 멤버변수들인 b,s,i,l,d,f,o 등은
아무런 초기화를 하지 않았지만 실제로 프린트를 해보면 기본값일이 출력되는 것을
알 수 있다.

 

FieldTest.java

PMDTestMain.java

 

결과

b = false
s = null
i = 0
l = 0
d = 0.0
f = 0.0
o = null


블로그 이미지

마즈다

이미 마흔을 넘어섰지만 아직도 꿈을 좇고 있습니다. 그래서 그 꿈에 다가가기 위한 단편들을 하나 둘 씩 모아가고 있지요. 이 곳에 그 단편들이 모일 겁니다...^^



NullAssignment

우선순위 : 3

코드 중간에서 변수에 null을 할당하는 것은 좋지 않은 형태이다.

이런 형태의 할당은 종종 개발자들이 프로그램의 흐름을 이해하지 못하고 코딩을 하고 있다는 표시가 될 수 있다.

주의 : 이런 형태의 경우가 드물게는 garbage collectoin에 도움이 되는 경우도 있다. (물론 잘 이해하고 사용했을

경우) 이렇게 의도하고 사용한 경우에는 이 룰을 무시해도 좋다.

 

샘플코드

 

부연 설명

이 경우 중요한 부부은 주석으로 표시된 ‘매우 크고 복잡한 코드’에 있다.

중간에 특정 변수를 null로 처리하는 경우 이를 제대로 인지하지 못하게 되면 뒤의 코드에서 null로 할당된

변수를 새로운 인스턴스로 할당하지 않고 바로 사용하게 될 소지가 있으며 이럴 경우 NullPointerException이

발생하게 될 것이다.

믈론 한 메소드 안에서 그렇게 길고 복잡한 코드를 사용하는 것 자체가 문제라면 문제지만…


OnlyOneReturn

우선순위 : 3

메소드에는 종료 포인트가 반드시 하나만 있어야 하며 이 종료 포인트는 반드시 메소드의 가장 마지막에

있어야 한다.

 

샘플코드 (나쁜 예)

 

부연 설명

이는 원칙적이고 일반적인 룰을 설명한 것이다.

흔히들 메소드 내에 if, if/else, while, for, try/catch등 각종 코드 블록이 만들어지고 각각의 블록에서

상황에 맞게 return문을 사용하는 경우가 많다. 상황에 따라 이렇게 할 수밖에 없는 경우도 있지만

이는 곧 코드의 복잡도(Cyclomatic Complexity)가 올라갔다는 반증이기도 하다.

가독성을 높이고 코드의 흐름을 원활하게 하기 위해서는 가능한한 return문은 하나만, 메소드의 가장

마지막에 위치할 수 있도록 하자.


AvoidLiteralsInIfCondition

우선순위 : 3

조건문의 조건식에 하드코딩 된 상수를 사용하지 말아라.

의미를 설명할 수 있는 이름을 가진 static 변수나 private 멤버 변수로 사용하는 것이 더 좋은 방법이다.

 

샘플코드

 

부연설명

위의 샘플코드에 ‘magic number’라는 표현이 나오는데 이 것은 Refactoring에서도 자주 언급되는 내용으로

마치 마술처럼 어떻게도 해석이 될 수 있다는 것을 빗댄 표현이다.

즉, 상수를 하드코딩해 놓았을 때 그 숫자 자체만으로는 어떤 의미인지 이해가 불가능하다.

따라서 이러한 숫자들은 static이나 private 멤버변수로 만들어 의미가 있는 이름으로 사용하도록

권장하고 있다.


UseObjectForClearerAPI

우선순위 : 3

public 메소드를 만들 때는 API 사용 조건에 대해 생각해야만 한다.

메소드를 public으로 만들었다는 것은 다른 클래스들에서 이 메소드를 사용하게 하는 것이고 따라서

보다 포괄적이고 개선된 API를 제공하고자 하는 것이다.

 

이런 경우 너무 많은 정보를 단순 나열 형태의 String으로 전달하게 된다면 이 파라미터들을 하나의 Object로

묶어 이 Object를 인자로 전달하는 것이 좋다. 일단 코딩이 길어지고 복잡해지는 것이나 파라미터의 갯수가

많음으로 해서 어떤 인자가 어떤 위치에 있어야 하는지에 대한 혼동을 줄일 수 있을 뿐더러 만일 전달해야 하는

파라미터의 수나 종류가 변경될 경우 이 Object만 수정하면 되기 때문이다.

 

샘플코드

 

블로그 이미지

마즈다

이미 마흔을 넘어섰지만 아직도 꿈을 좇고 있습니다. 그래서 그 꿈에 다가가기 위한 단편들을 하나 둘 씩 모아가고 있지요. 이 곳에 그 단편들이 모일 겁니다...^^

Tag java, pmd