Java 프로그래밍의 일반적인 질문 요약

본고는 내가 주위 동료들의 자바 코드에서 본 비교적 전형적인 오류들을 열거하였다.분명히 정적 코드 분석 (우리 팀이 사용하는 것은qulice) 은 모든 문제를 발견할 수 없다. 이것도 내가 여기에 그것들을 열거해야 하는 이유이다.
만약 당신이 부족한 것이 있다고 생각한다면, 아낌없이 가르침을 주십시오. 나는 그것들을 기꺼이 덧붙일 것입니다.
아래 나열된 모든 오류는 기본적으로 대상 프로그래밍, 특히 Java의 OOP와 관련이 있습니다.
유명
이 단문 "대상"을 읽어 보세요.클래스는 실제 생활의 추상적인 실체이지'validators','controller','managers'가 아니다.만약 당신의 클래스가'er'로 끝난다면, 그것은 엉망진창인 디자인이다.
물론 도구류도 반모드이다. 예를 들어 아파치의 StringUtils, FileUtils, 그리고 IOUtils 등이다.위의 이것들은 모두 엉망진창인 디자인의 대표이다.확장 읽기:OOP의 도구 클래스 대안 .
물론 접두사나 접두사를 사용하여 분류와 인터페이스를 구분하지 마세요.예를 들어 이 이름들은 잘못된 것입니다. IRecord, Iface Employee, 또는 Record Interface입니다.일반적으로 인터페이스 이름은 실제 생활의 실체 이름이고 클래스 이름은 그 실현의 세부 사항을 설명할 수 있어야 한다.만약 이 실현에 특별한 설명이 없다면, 그것을 Default, Simple 또는 유사한 것이라고 할 수 있다.예:

class SimpleUser implements User {};

class DefaultRecord implements Record {};

class Suffixed implements Name {};

class Validated implements Content {};

방법
방법은 값을 되돌릴 수도 있고void를 되돌릴 수도 있습니다.만약 방법이 값을 되돌려준다면, 그 이름은 그것이 무엇을 되돌렸는지 설명할 수 있을 것이다. 예를 들어 (get 접두사를 영원히 사용하지 마라.)

boolean isValid(String name);

String content();

int ageOf(File file);

만약 그것이void로 되돌아온다면, 그 이름은 그것이 무엇을 했는지 설명해야 한다.예:

void save(File file);

void process(Work work);

void append(File file, String line);

방금 언급한 이 규칙들은 단지 하나의 예외일 뿐이다. 즉, JUnit의 테스트 방법은 포함되지 않는다.다음은 이 얘기를 하겠습니다.
테스트 방법 이름
JUnit의 테스트 용례에서 방법명은 빈칸이 없는 영문어여야 한다.한 가지 예로 설명하면 더욱 명확해진다.

/**

 * HttpRequest can return its content in Unicode.

 * @throws Exception If test fails

 */

public void returnsItsContentInUnicode() throws Exception {

}

당신의 JavaDoc의 첫 번째 문장의 시작은 당신이 테스트할 클래스의 이름이고 그 다음은 can입니다.따라서 당신의 첫 마디는'somebody can do something'과 유사할 것입니다.
방법명도 마찬가지다. 단지 주제가 없을 뿐이다.만약 내가 방법명 중간에 주제를 추가한다면 나는 위의 예에서와 같이 완전한 문장을 얻을 수 있다. "HttpRequest returns its content in unicode".
테스트 방법의 이름은 can으로 시작하지 않습니다.JavaDoc의 주석만 can으로 시작됩니다.이외에 방법명은 동사로 시작해서는 안 된다.
실천 중에는 테스트 방법을 Exception을 던지는 것으로 성명하는 것이 가장 좋다.
변수 이름
조합된 변수 이름, 예를 들어 time OfDay,first Item, 또는 http Request를 피합니다.클래스 변수와 방법 내의 변수는 모두 이렇다.변수 이름은 가시적 작용역 내에서 잘못된 뜻이 생기지 않도록 충분히 길어야 하지만, 가능하다면 너무 길어서는 안 된다.이름은 단수나 복수 형식의 명사나 적당한 줄임말이어야 한다.예:

List<String> 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나 Stringstring.
여러 가지 다른 성질의 변수가 존재한다면 형용사를 고려해 볼 수 있다.예:

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"와 첫 줄의 같은 문자열 액면가가 결합되었습니다.만약 몇 달이 지나면, 누군가가 세 번째 줄의 이 값을 바꾸려고 한다면, 그는 같은 방법 중 어디에서도 이'제프'를 사용했는지 찾아내는 데 시간을 들여야 한다.
이런 상황을 피하기 위해서는 변수를 도입하는 것이 가장 좋다.