일반적인 프로그래밍 원칙

57. 지역변수의 범위를 최소화하라.

핵심 정리

• 지역변수의 범위를 줄이는 가장 강력한 기법은 역시 가장 처음 쓰일 때 선언하기다.
  • 사용하려면 멀었는데, 미리 선언부터 해두면 코드가 어수선해져 가독성이 떨어진다.
• 거의 모든 지역변수는 선언과 동시에 초기해야 한다.
  • 초기화에 필요한 정보가 충분하지 않다면 충분해질 때까지 선언을 미뤄야 한다.
• 메서드를 작게 유지하고 한 가지 기능에 집중하자.

58. 전통적인 for 문보다는 for-each 문을 사용하라.

핵심 정리

전통적인 for 문과 비교했을 때 for-each 문은 명료하고, 유연하고, 버그를 예방해준다.
성능 저하도 없다. 가능한 모든 곳에서 for 문이 아닌 for-each문을 사용하자.

59. 라이브러리를 익히고 사용하라.

핵심 정리

바퀴를 다시 발명하지 말자. 일반적으로 라이브러리 코드는 여러분이 직접 작성한 것보다 품질이 좋고, 점차 개선될 가능성이 크다.
코드 품질에도 규모의 경제가 적용된다. 즉, 라이브러리 코드는 개발자 각자가 작성하는 것보다 주목을 훨씬 많이 받으므로 코드 품질도 그만큼 높아진다.

60. 정확한 답이 필요하다면 float와 double은 피하라.

정확한 답이 필요한 계산에는 float나 double을 피하라.
소수점 추적은 시스템에 맡기고, 코딩 시의 불편함이나 성능 저하를 신경 쓰지 않겠다면 BigDecimal을 사용하라.

• BigDecimal이 제공하는 여덟 가지 반올림 모드를 이용하여 반올림을 완벽히 제어할 수 있다. 법으로 정해진 반올림을 수행해야 하는 비즈니스 계산에서 아주 편리한 기능이다.

반면, 성능이 중요하고 소수점을 직접 추적할 수 있고 숫자가 너무 크지 않다면 int나 long을 사용하라. 숫자를 아홉 자리 십진수로 표현할 수 있다면 int를 사용하고, 열여덟 자리 십진수로 표현할 수 있다면 long을 사용하라.
열여덟 자리를 넘어가면 BigDecimal을 사용해야 한다.

61. 박싱된 기본 타입보다는 기본 타입을 사용하라.

박싱과 언박싱의 차이

• 박싱된 타입은 객체 참조 값을 가진다.
• 박싱된 타입은 null 값을 가질 수 있다.
• 기본 타입이 박싱된 기본 타입보다 시간과 메모리면에서 효율적이다.

  핵심 정리

  기본 타입과 박싱된 기본 타입 중 하나를 선택해야 한다면 기본 타입을 사용하라.
  기본 타입은 간단하고 빠르다. 박싱된 객체 간의 비교에서 실수나 예기치 못한 에러를 발생시킬 수 있다.

62. 다른 타입이 적절하다면 문자열 사용을 피하라.

핵심 정리

더 적합한 데이터 타입이 있거나 새로 작성할 수 있다면, 문자열을 쓰고 싶은 유혹을 뿌리쳐라!!
문자열은 잘못 사용하면 번거롭고, 덜 유연하고, 느리고, 오류 가능성도 크다. 문자열을 잘못 하용하는 흔한 예로는 기본 타입, 열거 타입, 혼합 타입이 있다.

63. 문자열 연결은 느리니 주의하라.

핵심 정리

원칙은 간단하다. 성능에 신경 써야 한다면 많은 문자열을 연결할 때는 문자열 연결 연산자(+)를 피하자. 대신 StringBuilder의 append 메서드를 사용하라.
문자 배열을 사용하거나, 문자열을 (연결하지 않고) 하나씩 처리하는 방법도 있다.

64. 객체는 인터페이스를 사용해 참조하라.

핵심 정리

매개변수 타입으로 클래스가 아니라 인터페이스를 사용하라고 했었다. 이 조언을 “객체는 클래스가 아닌 인터페이스로 참조하라”고까지 확장할 수 있다.
적합한 인터페이스만 있다면 매개변수뿐 아니라 반환값, 변수, 필드를 전부 인터페이스 타입으로 선언하라
적합한 인터페이스가 없다면 클래스의 계층구조 중 필요한 기능을 만족하는 가장 덜 구체적인(상위의) 클래스를 타입으로 사용하자.

65. 리플렉션보다는 인터페이스를 사용하라.

핵심 정리

리플렉션은 복잡한 특수 시스템을 개발할 때 필요한 강력한 기능이지만, 단점도 많다.
컴파일 타임에는 알 수 없는 클래스를 사용하는 프로그램을 작성한다면 리플렉션을 사용해야 한다. 단, 되도록 객체 생성에만 사용하고, 생성한 객체를 이용할 때는 적절한 인터페이스나 컴파일 타임에 알 수 있는 상위 클래스로 형변환해 사용해야 한다.

66. 네이티브 메서드는 신중히 사용하라.

핵심 정리

네이티브 메서드를 사용하려거든 한번 더 생각하라. 네이티브 메서드가 성능을 개선해 주는 일은 많지 않다.
저수준 자원이나 네이티브 라이브러리를 사용해야만 해서 어쩔 수 없더라도 네이티브 코드는 최소한만 사용하고 철처지 테스트하라.
네이티브 코드 안에 숨은 단 하나의 버그가 애플리케이션 전체를 훼손할 수도 있다.

67. 최적화는 신중히 하라.

핵심 정리

빠른 프로그램을 작성하려고 안달하지 말자. 좋은 프로그램을 작성하다 보면 성능은 따라오기 마련이다.
하지만 시스템을 설계할 때, API, 네트워크 프로토콜 등을 설계할 때는 성능을 염두해야 한다. 시스템 구현이 완료되었다면 성능을 측정하고 충분히 빠르면 그것으로 끝이다.
그렇지 않다면 프로파일러를 사용하고 원인이 되는 지점을 찾아 최적화하라. 가장 먼저 알고리즘을 사용한 곳을 찾아서 살펴 보자.

68. 일반적으로 통용되는 명명 규칙을 따르라.

핵심 정리

표준 명명 규칙을 체화하여 자연스럽게 베어 나오도록 하자. 철차 규칙은 직관적이라 모호한 부분이 적은 데 반해, 문법 규칙은 더 복잡하고 느슨하다.
자바 언어 명세의 말을 인용하자면 “오랫동안 따라온 규칙과 충돌한다면 그 규칙을 맹종해서는 안 된다.” 상식이 이끄는 대로 따르자.

통용되는 명명 규칙

추가적으로 흔히사용되는 명명 메서드

etc: from, of, valueOf, instance, getInstance, newInstance, getType, newType