뭔가 잘못되면 바로 잡을 책임은 프로그래머에게 있다. # 정리 오류가 발생하면 예외를 던지는 것이 낫다. 예외가 발생할 코드를 짤 때는 try-catch-finally 문으로 시작하는 편이 낫다. try블록에서 무슨 일이 생기든 호출자가 기대하는 상태를 정의하기 쉬워진다. 예외를 던질 때는 전후 상황을 충분히 덧붙여야 오류가 발생한 원인과 위치를 찾기가 쉽다. 호출자를 고려해 예외 클래스를 정의하는 것이 좋다. null은 반환하지도 전달하지도 마라!!! # 결론 깨끗한 코드는 읽기도 좋아야 하지만 안정성도 높아야 한다. 오류 처리를 프로그램 논리와 분리하면 깨끗한 코드를 작성할 수 있다. 그로 인해 코드 유지보수성도 좋아질 수 있다.
클린코드
변수를 private로 정의하는 이유는 남들이 변수에 의존하지 않게 만들고 싶어서이다. #1. 자료 추상화 추상 인터페이스를 제공해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 진정한 의미의 클래스이다. 개발자는 객체가 포함하는 자료를 표현할 가장 좋은 방법을 심각하게 고민해야 한다. #2. 자료/객체 비대칭 새로운 자료 타입이 필요한 경우에는 클래스와 객체 지향 기법이 가장 적합하다. 새로운 함수가 필요한 경우에는 절차적인 코드와 자료 구조가 더 적합하다. 모든 코드를 객체를 이용하는 것이 좋은 것이 아니고 때로는 단순한 자료 구조와 절차적인 코드가 적합할 때도 있다. #3. 디미터 법칙 디미터 법칙이란 "모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다는 법칙"이다. #4. 자료 전달 ..
#1. 주석은 나쁜 코드를 보완하지 못한다. 표현력이 풍부하고 깔끔하며 주석이 거의 없는 코드가, 복잡하고 어수선하며 주석이 많이 달린 코드보다 훨씬 좋다. 주석으로 설명하려 애쓰지 말고 그 시간에 코드를 더욱 분명하게 짜는 것이 좋다. #2. 좋은 주석의 종류 의도를 설명하는 주석 의미를 명료하게 밝히는 주석 결과를 경고하는 주석 TODO 주석 중요성을 강조하는 주석 위의 주석들은 그래도 좋은 주석이라 칭하지만 그래도 주석을 달지 않고 더 좋게 나타낼 수는 없는지 고민하고 주석을 사용하더라도 올바른 사용을 해야 한다. 잘못된 주석 사용은 사용하지 않은 것보다 더 잘못된 정보를 줄 수 있다. #3. 나쁜 주석의 종류 주절거리는 주석 같은 이야기를 중복하는 주석 오해할 여지가 있는 주석 의무적으로 다는 주..
