1. 매개변수가 유효한지 검사하라.

• 메서드나 생성자를 작성할 때문 그 매개변수들에 어떤 제약이 있을지 생각해야 한다.
• 그 제약들을 문서화하고 메서드 코드 시작 부분에서 명시적으로 검사해야 한다.
• 이런 습관을 반드시 기르도록 하자.
  그 노력은 유효성 검사가 실제 오류를 처음 걸러낼 때 충분히 보상받을 것이다.

2. 적시에 방어적 복사본을 만들라.

• 클래스가 클라이언트로부터 받는, 혹은 클라이언트로 반환하는 구성요소가 가변이라면 그 요소는 반드시 방어적으로 복사해야 한다.
• 복사 비용이 너무 크거나 클라이언트가 그 요소를 잘못 수정할 일이 없음을 신뢰한다면 방어적 복사를 수행하는 대신 해당 구성요소를 수정했을 때의 책임이 클라이언트에 있음을 문서에 명시하도록 하자.

3. 메서드 시그나처를 신중히 설계하라.

• 메서드 이름을 신중히 짓자.
• 편의 메서드를 너무 많이 만들지 말자.
• 매개변수 목록은 짧게 유지하자.
• 매개변수의 타입으로는 클래스코다는 인터페이스가 더 낫다.
• boolean 보다는 원소 2개짜리 열거 타입이 낫다.

4. 다중정의는 신중히 사용하라.

• 프로그래밍 언어가 다중정의를 허용한다고 해서 다중정의를 꼭 활용하라는 뜻은 아니다.
• 일반족으로 매개변수 수가 같을 때는 다중정의를 피하는 게 좋다.
• 상황에 따라, 특히 생성자라면 이 조언을 따르기 불가능할 수 있다. 그럴 때는 헷갈릴 만한 매개변수는 형변환하여 정확한 다중정의 메서드가 선택되도록 해야 한다.
• 이것이 불가능하다면, 예컨데 기존 클래스를 수정해 새로운 인터페이스를 구현해야 할 때는 같은 객체를 입력받는 다중정의 메서드들이 모두 동일하게 동작하도록 만들어야 한다.
• 그렇지 못하면 프로그래머들은 다중정의된 메서드나 생성자를 효과적으로 사용하지 못할 것이고, 의도대로 동작하지 않는 이유를 이해하지 못할 것이다.

5. 가변인수는 신중히 사용하라.

• 인수 개수가 일정하지 않은 메서드를 정의해야 한다면 가변인수가 반드시 필요하다.
• 메서드를 정의할 때 필수 매개변수는 가변인수 앞에 두고, 가변인수를 사용할 때는 성능 문제까지 고려하자.

6. null이 아닌 빈 컬렉션이나 배열을 반환하라.

• null이 아닌 빈 배열이나 컬렉션을 반환하라.
• null을 반환하는 API는 사용하기 어렵고 오류 처리 코드도 늘어난다. 그렇다고 성능이 좋은 것도 아니다.

7. Optional 반환은 신중히 하라.

• 값을 반환하지 못할 가능성이 있고, 호출할 때마다 반환값이 없을 가능성을 염두에 둬야 하는 메서드라면 Optional을 반환해야 하는 상황일 수 있다.
• 하지만 Optional 반환에는 성능 저하가 뒤따르니, 성능에 민감한 메서드라면 null을 반환하거나 예외를 던지는 편이 나을 수 있다.
• Optional을 반환값 이외의 용도롤 쓰는 경우는 매우 드물다.