Java 코드의 일반적인 오류입니다.

이 자료에는 나와 함께 일하는 사람들의 Java 코드에서 본 가장 일반적인 오류가 포함되어 있습니다. 명백한 이유로 정적 분석(우리는 qulice 사용 )은 이러한 오류를 모두 감지할 수 없으므로 여기에 나열하기로 결정했습니다. 이러한 오류는 모두 일반적인 객체 지향 프로그래밍, 특히 Java와 관련이 있습니다.

클래스 이름

귀하의 클래스는 " 유효성 검사기 " , " 컨트롤러 " , " 관리자 " 등이 없는 실제 객체의 추상화여야 합니다 . 클래스 이름이 "-er"로 끝나면 잘못된 디자인입니다. 물론 Apache의 StringUtils , FileUtils 및 IOUtils 와 같은 안티패턴 도우미 클래스 는 끔찍한 디자인 패턴의 좋은 예입니다. 인터페이스와 클래스를 구별하기 위해 접미사 또는 접두사를 추가하지 마십시오. 예를 들어, IRecord , IfaceEmployee 또는 RecordInterface 와 같은 이름은 모두 끔찍합니다 . 일반적으로 인터페이스 이름은 실제 개체의 이름이고, 클래스 이름은 구현 세부 사항을 설명해야 합니다. 구현에 대해 구체적으로 언급할 수 없는 경우 " Default ", " Simple " 또는 이와 유사한 이름을 사용하면 됩니다. 예를 들어: class SimpleUser implements User {}; class DefaultRecord implements Record {}; class Suffixed implements Name {}; class Validated implements Content {};

메소드 이름

메소드는 " something "을 반환 하거나 " void "를 반환할 수 있습니다. 메소드가 무언가를 반환하는 경우 해당 이름은 반환될 내용을 설명해야 합니다. 예를 들어(" get " 접두사를 사용하지 마세요 ): boolean isValid(String name); String content(); int ageOf(File file); " void "가 반환되면 이름은 메서드가 수행하는 작업을 명확히 해야 합니다. 예를 들면 다음과 같습니다. 이 규칙에는 JUnit void save(File file); void process(Work work); void append(File file, String line); 테스트 방법 이라는 단 하나의 예외가 있습니다 . 아래에 설명되어 있습니다.

테스트 방법 이름

JUnit 테스트의 메소드 이름은 공백 없이 영어 문장으로 구성되어야 합니다. 예를 들어 설명하는 것이 더 쉽습니다. /** * HttpRequest can return its content in Unicode. * @throws Exception If test fails */ public void returnsItsContentInUnicode() throws Exception { } JavaDoc의 첫 번째 문장을 테스트 중인 클래스 이름과 " can "으로 시작하는 것이 중요합니다. 따라서 첫 번째 문장은 항상 " 누군가는 뭔가를 할 수 있다 " 라는 문구와 같아야 합니다 . 메소드 이름은 동일한 내용을 나타내지만 테스트 대상은 없습니다. 메서드 이름의 시작 부분에 추가하면 위의 예와 같이 완전한 영어 문장이 표시됩니다. " HttpRequest는 해당 콘텐츠를 유니코드로 반환합니다 ." 테스트 메소드 이름은 “ can ”으로 시작하지 않는다는 점에 유의하세요. JavaDoc 주석만 " can "으로 시작합니다. 또한 메소드 이름은 동사로 시작해서는 안 됩니다( 번역자의 말에 따르면, 분명히 저자는 동사의 명령형을 의미한다고 합니다 ). 테스트 메서드를 선언할 때 예외가 발생했음을 나타내는 것이 좋습니다.

변수 이름

timeOfDay , firstItem 또는 httpRequest 와 같은 복합 변수 이름을 사용하지 마세요 . 클래스 변수와 메소드 변수를 모두 의미합니다. 변수 이름은 해당 범위에서 모호함을 피할 수 있을 만큼 길어야 하지만 가능하면 너무 길지 않아야 합니다. 이름은 단수 또는 복수 명사여야 합니다. 예: 생성자가 생성된 객체에 입력 데이터를 저장하는 경우 생성자 매개변수와 클래스 필드 사이에 충돌이 발생할 수 있습니다. 이 경우 모음을 제거하여 약어를 생성하는 것이 좋습니다. 예: 대부분의 경우 가장 좋은 변수 이름은 해당 클래스의 이름입니다. 그냥 대문자로 쓰면 괜찮을 것입니다. 그러나 또는 같은 기본 유형에 대해서는 절대로 동일한 작업을 수행하지 마십시오 . 특성이 다른 여러 변수가 있는 경우에도 형용사를 사용할 수 있습니다. 예를 들어: List names; void sendThroughProxy(File file, Protocol proto); private File content; public HttpRequest request; public class Message { private String recipient; public Message(String rcpt) { this.recipient = rcpt; } } File file; User user; Branch branch; Integer number String string String contact(String left, String right);

생성자

예외 없이 객체 변수에 데이터를 저장하는 생성자는 하나만 있어야 합니다. 다른 모든 생성자는 다른 매개변수를 사용하여 이 생성자를 호출해야 합니다. public class Server { private String address; public Server(String uri) { this.address = uri; } public Server(URI uri) { this(uri.toString()); } }

일회성 변수

어떤 일이 있어도 일회성 변수를 피하세요. "일회용"이란 한 번 사용되는 변수를 의미합니다. 이 예에서와 같이 String name = "data.txt"; return new File(name); 변수는 한 번만 사용되며 코드는 다음과 같이 단순화될 수 있습니다. return new File("data.txt"); 때로는 매우 드문 경우(주로 더 나은 형식화로 인해) 일회성 변수를 사용할 수 있습니다. 그러나 그러한 상황을 피하려고 노력하십시오.

예외.

물론, 예외를 절대로 "삼켜서는" 안 되며, 가능한 한 높게 던져야 합니다. 개인 메소드의 예외는 외부에서 처리되어야 합니다. 흐름을 제어하기 위해 예외를 사용하지 마십시오. 예제의 코드가 잘못되었습니다. int size; try { size = this.fileSize(); } catch (IOException ex) { size = 0; } IOException에 "디스크가 꽉 찼습니다"라고 표시되면 파일 크기가 0이라고 가정하고 계속 진행하시겠습니까?

들여 쓰기.

들여쓰기의 경우 일반적인 규칙은 괄호가 줄을 끝내거나 같은 줄에서 끝나야 한다는 것입니다(닫는 괄호에는 반대 규칙이 적용됩니다). 아래 예에서는 첫 번째 괄호가 같은 줄에서 닫히지 않고 그 뒤에 문자가 있기 때문에 코드가 올바르지 않습니다. 두 번째 대괄호 앞에는 문자가 있고 현재 줄에는 여는 대괄호가 없기 때문에 동일한 문제가 있습니다. final File file = new File(directory, "file.txt"); 올바른 들여쓰기는 다음과 같아야 합니다. StringUtils.join( Arrays.asList( "first line", "second line", StringUtils.join( Arrays.asList("a", "b") ) ), "separator" ); 들여쓰기의 두 번째 중요한 규칙은 가능한 한 많은 내용을 한 줄(80자 이내)에 배치해야 한다는 것입니다. 위의 예는 압축될 수 있으므로 유효하지 않습니다. StringUtils.join( Arrays.asList( "first line", "second line", StringUtils.join(Arrays.asList("a", "b")) ), "separator" );

중복 상수.

클래스 상수는 클래스 메소드 간에 정보에 대한 접근을 공유하고 싶을 때 사용해야 하며, 이 정보는 클래스의 특징( ! )입니다. 문자열이나 숫자 리터럴을 대신하여 상수를 사용하지 마세요. 매우 나쁜 습관입니다. 코드가 오염될 수 있습니다. 다른 OOP 객체와 마찬가지로 상수는 실제 세계에서 의미를 가져야 합니다. 실제 세계에서 이러한 상수의 의미는 무엇입니까? class Document { private static final String D_LETTER = "D"; // bad practice private static final String EXTENSION = ".doc"; // good practice } 또 다른 일반적인 실수는 테스트 메서드에서 문자열/숫자 리터럴의 중복을 피하기 위해 단위 테스트에서 상수를 사용하는 것입니다. 그거 하지마! 각 테스트 방법은 자체 입력 값 세트에서 작동해야 합니다. 각각의 새로운 테스트 방법에 새로운 텍스트와 숫자를 사용하십시오. 테스트는 독립적입니다. 그렇다면 왜 동일한 입력 상수를 공유해야 할까요?

테스트 데이터 커플링.

다음은 테스트 메소드를 후킹하는 예입니다: User user = new User("Jeff"); // maybe some other code here MatcherAssert.assertThat(user.name(), Matchers.equalTo("Jeff")); 마지막 줄에서는 " Jeff "를 첫 번째 줄에 지정된 동일한 문자열 리터럴과 연결합니다. 몇 달 후 누군가가 세 번째 줄의 값을 변경하려는 경우 이 방법에서 " Jeff "가 사용 된 다른 위치를 검색하는 데 추가 시간을 소비해야 합니다 . 이러한 데이터 걸림을 방지하려면 변수를 도입해야 합니다.