"ThreadGroup"을 사용해선 안됩니다
ThreadGroup 클래스의 메소드를 사용할 이유가 없습니다.
어떤 코드들(allowThreadSuspension(), resume(), stop(), suspend())은 이미 deprecated 되었습니다.
그리고 어떤 코드(activeCount(), enumerate())는 구시대적인 코드이며, thread-safe 하지도, 안전하지도 않습니다.
이러한 이유로 ThreadGroup을 사용하는 것은 불안정하므로 피해야 합니다.
규칙을 준수한 해결책
ThreadFactory threadFactory = Executors.defaultThreadFactory();
ThreadPoolExecutor execut...
public 이 아닌 메소드는 "@Transactional" 을 사용해서는 안됩니다.
public 이 아닌 메소드에 @Transactional 어노테이션을 다는것은 쓸모없고 오해의 소지가 있습니다.
스프링은 public 메소드가 아닌 메소드를 보지 않고, 그로 인해 트랜잭션 설정을 하지 않기 때문입니다.
또한, 스프링은 내부의 다른 메소드에 의해 호출된 메소드에 대해서도 트랜잭션 설정을 제공하지 않습니다.
따라서, @Transactional 어노테이션을 private 메소드에 다는경우, 런타임 에러 혹은 예외를 초래할 수 있습니다.
규칙을 어긴 코드
@Transactional // 규칙을 어긴 코드
private void doTheThing(ArgClass arg) {
// ...
}...
"CHECKSTYLE:OFF"" 억제 주석을 추적할 수 있습니다.
해당 규칙을 사용하면 Checkstyle에서 사용한 억제 주석을 추적할 수 있습니다.
규칙을 어긴 코드
// CHECKSTYLE:OFF
If you like SONARKUBE, don’t forget to give me a star.
원문으로 바로가기
"NOPMD" 억제 주석을 추적할 수 있습니다.
해당 규칙을 사용하면 PMD에서 사용한 억제 주석을 추적할 수 있습니다.
규칙을 어긴 코드
// NOPMD
If you like SONARKUBE, don’t forget to give me a star.
원문으로 바로가기
"NOSONAR"" 주석을 추적할 수 있습니다.
품질 규칙에 의해 발견되는 문제들은 “NOSONAR” 마커를 통해 비활성화할 수 있습니다. 해당 마커는 잘못된 결과를 제외하는데에는 꽤 유용하지만, 실제로 결함이 있는 부분을 숨기는데 남용될 수 있습니다.
해당 규칙운 “NOSONAR”가 사용될 때 문제를 제기합니다.
If you like SONARKUBE, don’t forget to give me a star.
원문으로 바로가기
String 리터럴이 중복 사용되어선 안됩니다.
중복된 String 리터럴 사용은 변경시 모든 항목을 업데이트해야 하므로, 리팩토링 과정에서 실수를 하기 쉽게 만듭니다.
반면 상수를 이용하면 여러 위치에서 참조할 수도 있고, 한 곳에서만 업데이트하면 되므로 편리합니다.
규칙을 어긴 코드
규칙이 동작하는 기본 중복 수치는 3입니다.
public void run() {
prepare("action1"); // 규칙을 어긴 코드 - "action1" 이 3번 중복되어 사용되었습니다
execute("action1");
release("action1");
}
@SuppressWarning("all")...
문자열 리터럴이 같은지 비교할 때는 왼쪽에 배치하여야 합니다.
equals() 또는 equalsIgnoreCase() 함수를 호출 할 때 문자열 리터럴을 왼쪽에 배치하는 것이 좋습니다.
문자열 리터럴이 null 이 될 수 없기 때문에, NPE(null point exception)이 발생하는 것을 예방할 수 있습니다.
규칙을 어긴 코드
String myString = null;
System.out.println("Equal? " + myString.equals("foo")); // 규칙을 어긴 코드; NPE를 발생시킵니다.
System.out.println("Equal? " + (myString != null &&...
"Consumer" 인수를 사용하는 "AssertJ assertions"는 Consumer 인터페이스 안에 "assertion"을 포함해야 합니다.
Consumer 객체를 인수로 사용하는 AssertJ assertions는 그 자체가 assertions로 표현되어야 하는 requirements를 포함할 것으로 예상됩니다. 다음 열거되는 함수가 이에 해당됩니다: allSatisfy, anySatisfy, hasOnlyOneElementSatisfying, isInstanceOfSatisfying, noneSatisfy, satisfies, satisfiesAnyOf, zipSatisfy.
이 함수들은 Consumer가 assertions를 직접 수행한다고 가정합니다. 만약 Consumer가 어떤 assertion도 수행하지 않는다면, 아마도 객체를 부분적으로만...
전체 글 239개, 30 페이지