홈

조건문에 괄호가 없는 경우, 바로 뒤에 있는 한 줄은 조건적으로 실행된다는 의미입니다. 관례적으로도 그렇고, 이 실행 라인은 들여쓰기되는 것이 모범적입니다. 괄호도 없고 들여쓰기도 되지 않는다면, 이 코드를 작성한 프로그래머의 의도가 제대로 파악되지 않고, 실은 실행되지 않기를 바라는 것일 수도 있습니다. 또한 이러한 코드는 코드베이스를 유지 관리해야하는 maintainer들도 혼란스럽게 만듭니다. 규칙을 어긴 코드 if (condition) // 규칙을 어긴 코드 doTheThing(); doTheOtherThing(); somethingElseEntirely(); foo(); 규칙을 준수한 해결책 ...

필드 주입은 클래스가 작업을 수행하기 위해 필요한 것을 얻는 깔끔한 방법처럼 보이지만, 실제로는 모든 너의 클래스의 생성자가 private 이 아닌 이상 NullPointerException 이 발생하는 것을 기다리고 있는 것과 같습니다. 왜나하면 JSR-330 을 준수한 의존성 주입 프레임워크(Spring, Guice, …) 에 의해 인스턴스화된 것이 아닌 호출자에 의해 생성된 클래스 인스턴스들은 필드 주입을 수행할 수 없기 때문입니다. @Inject 어노테이션을 사용하는 대신 필요한 필드를 생성자 및 생성자의 매개변수로 이동해야합니다. 이 규칙은 private 이 아닌 생성자를 가진 클래스(default c...

코드의 명확성을 지키기 위해 상위 클래스의 static 멤버에 접근할 때는 파생 클래스를 통해 접근해선 안됩니다. 이렇게 하는 것은 사용자를 혼란스럽게 만들고 두 개의 다른 static 멤버가 존재하는 것 같이 느껴지게 만듭니다. 규칙을 어긴 코드 class Parent { public static int counter; } class Child extends Parent { public Child() { Child.counter++; // 규칙을 어긴 코드 } } 규칙을 준수한 해결책 class Parent { public static int counter; } class Ch...

for 루프의 카운터가 increment 절 외부에서 증가할 경우 매우 혼란스러운 상황을 야기합니다. 가능한 카운터의 증가는 루프의 increment 절로 이동해야 합니다. 규칙을 어긴 코드 for (i = 0; i < 10; j++) { // 규칙을 어긴 코드 // ... i++; } 규칙을 준수한 해결책 for (i = 0; i < 10; i++, j++) { // ... } 또는 for (i = 0; i < 10; i++) { // ... j++; } If you like SONARKUBE, don’t forget to give me a star. :st...

관련 없는 두 클래스에 동일한 이름의 변수가 있는 것은 상관없습니다. 하지만 같은 계보에 있는 두 클래스에 같은 일이 벌어질 경우, 다행히도 잠깐 헷갈리는 정도일 수도 있지만 최악의 경우에는 치명적인 버그를 야기합니다. 규칙을 어긴 코드 public class Fruit { protected Season ripe; protected Color flesh; // ... } public class Raspberry extends Fruit { private boolean ripe; // 규칙을 어긴 코드 private static Color FLESH; // 규칙을 어긴 코드 } 규칙을 ...

특정 클래스의 메소드와 필드, 그리고 그 클래스의 상위 클래스에 있는 메소드와 필드들에 대해, 대소문자 몇 개로 구분하게 하는 것은 사용자에게 큰 혼란을 줍니다. 더불어 같은 클래스 내부에서 접근 제어자도 같은데 메소드 이름과 필드의 이름을 정확히 같게 만들거나, 대소문자로 구분하게 하는 것도 혼란스럽게 만듭니다. 메소드의 이름이 유사할 경우, 슈퍼클래스 메소드를 오버라이드하려고 한 것인지, 새로운 메소드를 추가하고 싶었던 것인지 의도를 파악할 수 없습니다. 만약 새로운 메소드를 추가하고 싶었던 것이라면, 네이밍이 최악이었다는 반증입니다. 메소드 이름은 action을 지향해야합니다. 그래서 동사를 포함해야합니다...

다수의 테스트가 몇가지 하드코딩된 값만 다를 경우, 한 개의 “parameterized” 테스트로 리팩토링되어야 합니다. 이러한 방법은 버그를 추가할 가능성을 줄어들게 하고 더 쉽게 읽혀지게 합니다. Parameterized 테스트는 다양한 테스트 프레임워크에 존재합니다.(JUnit, TestNG, 등등…) 물론 적당한 균형은 찾아야됩니다. Parameterized 테스트가 기존 버전보다 더 복잡성을 가지게 된다면 분해하는 의미가 없습니다. 해당 규칙은 최소 3개의 테스트가 4개의 파라미터를 가지는 parameterized 테스트로 리팩토링이 가능할 때 문제를 제기합니다. 적어도 한개의 중복된 상태를 가지는 테...

Thread.sleep을 테스트에 사용하는 것은 일반적으로 나쁜 생각입니다. 환경(내 환경에서는 통과!)이나 부하에 따라 예측할 수 없이 실패할 수 있는 불안정한 테스트를 생성합니다 타이밍에 의존하지 말거나(mock을 사용) Awaitility와 같은 비동기 테스트 라이브러리를 사용하십시오. 규칙을 어긴 코드 예제 @Test public void testDoTheThing(){ MyClass myClass = new MyClass(); myClass.doTheThing(); Thread.sleep(500); // 규칙을 어긴 코드 // assertions... } 규칙을 준수한 해결책 @...