홈

클래스와 같은 이름의 멤버를 가지는 것은(대소문자를 제외하더라도) 혼란스럽습니다. 이것은 특히 클래스의 인스턴스의 이름을 지정하는 일반적인 관습을 고려할 때 특히 그렇습니다. 클래스의 이름과 같은 멤버나 필드가 나타내거나, 가질 수 있는 특정한 측면을 더 잘 반영하도록 이름을 변경하는 것이 좋은 관습입니다. 규칙을 어긴 코드 public class Foo { private String foo; public String getFoo() { } } Foo foo = new Foo(); foo.getFoo() // 이것은 무엇을 리턴해야 하나요? 규칙을 준수한 해결책 public class ...

switch 문에 너무 많은 case 절이 있는 경우는 일반적으로 두 데이터 집합을 매핑하려는 시도입니다. 실제 map 구조는 더 읽기 쉽고, 유지보수하기 쉬우므로, switch 구문 대신 map 구조를 사용해야합니다. 예외 이 규칙은 열거형(Enum) 및 empty(case 의 조건이 없는경우), fall-through(break 구문을 생략하여 다음 case 로 넘기는 경우)는 무시합니다. If you like SONARKUBE, don’t forget to give me a star. 원문으로 바로가기

무언가를 할 수 있다는 의미가 그렇게 해야한다는 의미는 아닙니다. 3항 연산자를 중첩하는 경우도 마찬가지입니다. 3항 연산자를 중첩하면 코드를 작성할 당시에는 명확해보이지만, 6개월후, 유지 보수하는 사람 입장에서는 이해가 되질 않습니다. 머리를 긁적이며 당신을 욕하겠죠. 명확하게 하기위해, 중첩된 작업을 별도의 구문으로 분리하여 작성하십시오. 규칙을 어긴 코드 public String getReadableStatus(Job j) { return j.isRunning() ? "Running" : j.hasErrors() ? "Failed" : "Succeeded"; // 규칙을 어긴 코드 } 규칙을 ...

synchronization의 목적은 하나의 스레드에서만 지정된 코드를 실행할 수 있도록 하는 것입니다. writeObject를 synchronized로 선언하는 것은 실제로는 문제가 없습니다. 하지만 클래스 내 synchronized 선언된 writeObject가 동기화와 관련된 유일한 메서드인 것은 이해가 되질 않습니다. 규칙을 어긴 코드 public class RubberBall { private Color color; private int diameter; public RubberBall(Color color, int diameter) { // ... } public voi...

Serializable 객체가 파일에서 rehydrate를 할 때readObject 메서드는 특별히 다뤄줘야합니다. readObject에 의해 만들어지는 객체는 메소드를 호출한 스레드에서만 가시성이 생깁니다. 결과적으로 synchronized 키워드는 필요하지 않습니다. 그리고 synchronized을 사용하는 것은 혼란스럽기만 합니다. 이 메서드는 리팩토링되야합니다. 규칙을 어긴 코드 private synchronized void readObject(java.io.ObjectInputStream in) throws IOException, ClassNotFoundException { // 규칙을 어긴 ...

try/catch을 중첩하면 소스 코드의 가독성에 심각한 영향을 미칩니다. 중첩된 try/catch는 어떤 블락에서 어떤 예외가 catch될 지 이해할 수 없게 만듭니다. If you like SONARKUBE, don’t forget to give me a star. 원문으로 바로가기

빈 리스트에서 사용된 AssertJ assertion의 allMatch와 doesNotContains는 어떤 predicate를 작성하던 항상 참을 반환합니다. 만약 빈 리스트를 예상하는 경우에도 isEmpty() 함수나 isNotEmpty()를 추가하거나 리스트 값을 먼저 테스트해야 하여 명확하게 해야합니다. 쓸모 없는 predicate를 명확하게 하거나 테스트의 신뢰성을 향상시킬 것입니다. 이 규칙은 다음 타켓 함수들이 리스트가 비어있는지 확인하는 assertion 없이 사용되거나 리스트의 값을 테스트하지 않는 경우 문제를 제기합니다. 타겟 함수: allMatch allSatisfy doesN...

org.junit.rules.ExpectedException를 예외를 테스트할 때, 예외가 발생한 다음 코드는 실행되지 않을 것입니다. 따라서 assertion을 예외가 발생한 뒤에 붙이는 것은 잘못된 것이고 오해의 소지가 있습니다. 이 규칙은 expect() 함수 호출 뒤에 assertion이 불려지는 경우 문제를 제기하며 예상된 예외를 던지는 코드만 expect() 다음에 와야 합니다. org.junit.Assert.assertThrows를 사용하는 것을 고려할 수 있습니다. 해당 함수는 JUnit 4.13 부터 사용 가능하며 추가적인 후속 assertion을 허용합니다. 또는, JUnit 4.13 버전 ...