뭔가 잘못되면 바로 잡을 책임은 프로그래머에게 있다. # 정리 오류가 발생하면 예외를 던지는 것이 낫다. 예외가 발생할 코드를 짤 때는 try-catch-finally 문으로 시작하는 편이 낫다. try블록에서 무슨 일이 생기든 호출자가 기대하는 상태를 정의하기 쉬워진다. 예외를 던질 때는 전후 상황을 충분히 덧붙여야 오류가 발생한 원인과 위치를 찾기가 쉽다. 호출자를 고려해 예외 클래스를 정의하는 것이 좋다. null은 반환하지도 전달하지도 마라!!! # 결론 깨끗한 코드는 읽기도 좋아야 하지만 안정성도 높아야 한다. 오류 처리를 프로그램 논리와 분리하면 깨끗한 코드를 작성할 수 있다. 그로 인해 코드 유지보수성도 좋아질 수 있다.
clean code
변수를 private로 정의하는 이유는 남들이 변수에 의존하지 않게 만들고 싶어서이다. #1. 자료 추상화 추상 인터페이스를 제공해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 진정한 의미의 클래스이다. 개발자는 객체가 포함하는 자료를 표현할 가장 좋은 방법을 심각하게 고민해야 한다. #2. 자료/객체 비대칭 새로운 자료 타입이 필요한 경우에는 클래스와 객체 지향 기법이 가장 적합하다. 새로운 함수가 필요한 경우에는 절차적인 코드와 자료 구조가 더 적합하다. 모든 코드를 객체를 이용하는 것이 좋은 것이 아니고 때로는 단순한 자료 구조와 절차적인 코드가 적합할 때도 있다. #3. 디미터 법칙 디미터 법칙이란 "모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다는 법칙"이다. #4. 자료 전달 ..
#1. 형식을 맞추는 목적 코드 형식은 너무나 중요하다!!! #2. 적절한 행 길이를 유지하라 1. 신문 기사처럼 작성하라 이름은 간단하면서도 설명이 가능하게 짓는다. 소스파일 첫 부분은 고차원 개념과 알고리즘을 설명한다. 아래로 내려갈수록 의도를 세세하게 묘사해라. 2. 개념은 빈 행으로 분리하라 거의 모든 코드는 위에서 아래로, 왼쪽에서 오른쪽으로 읽힌다. 빈 행은 새로운 개념을 시작한다는 시각적 단서다. 3. 세로 밀집도 줄 바꿈이 개념을 분리한다면 세로 밀집도는 연관성을 의미한다. 서로 밀접한 코드 행은 세로로 가까이 놓아야 한다. 4. 수직 거리 서로 밀접한 개념은 세로로 가까이 두는 것으로 연관성을 표현한다. 연관성이란 한 개념을 이해하는 데 다른 개념이 중요한 정도다. 5. 변수, 함수 변수..
#1. 주석은 나쁜 코드를 보완하지 못한다. 표현력이 풍부하고 깔끔하며 주석이 거의 없는 코드가, 복잡하고 어수선하며 주석이 많이 달린 코드보다 훨씬 좋다. 주석으로 설명하려 애쓰지 말고 그 시간에 코드를 더욱 분명하게 짜는 것이 좋다. #2. 좋은 주석의 종류 의도를 설명하는 주석 의미를 명료하게 밝히는 주석 결과를 경고하는 주석 TODO 주석 중요성을 강조하는 주석 위의 주석들은 그래도 좋은 주석이라 칭하지만 그래도 주석을 달지 않고 더 좋게 나타낼 수는 없는지 고민하고 주석을 사용하더라도 올바른 사용을 해야 한다. 잘못된 주석 사용은 사용하지 않은 것보다 더 잘못된 정보를 줄 수 있다. #3. 나쁜 주석의 종류 주절거리는 주석 같은 이야기를 중복하는 주석 오해할 여지가 있는 주석 의무적으로 다는 주..
#1. 작게 만들어라 함수를 만드는 첫째 규칙은 '작게!'다. 둘째 규칙은 '더 작게!'다. if문, else문, while문 등에 들어가는 블록은 한 줄이면 좋다. 중첩 구조가 생길만큼 함수가 커져서는 안 된다. 들여쓰기 수준은 1단이나 2단까지만 사용하자. #2. 한가지만 해라! 함수는 한 가지를 해야 한다. 한 가지를 잘해야 한다. #3. 함수 당 추상화 수준은 하나로! 함수가 확실히 한 가지 작업만 하려면 함수 내 모든 문장의 추상화 수준이 동일해야 한다. 코드는 위에서 아래로 이야기처럼 읽혀야 좋다. #4. 서술적인 이름을 사용하라. 길고 서술적인 이름이 짧고 어려운 이름보다 좋다. 길고 서술적인 이름이 길고 서술적인 주석보다 좋다. 여러 단어가 쉽게 읽히는 명명법을 사용한다. 모듈 내에서 함수..
#1. 의도를 분명히 밝혀라 좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많기 때문에 중요하다. 함수, 클래스 이름을 보고 존재이유, 수행 기능, 사용 방법을 알 수 있어야 한다. 주석이 필요하다면 의도를 분명히 드러내지 못했다는 것이다. #2. 그릇된 정보는 피하라 프로그래머는 코드에 그릇된 정보를 남겨서는 안 된다. 서로 흡사한 이름을 사용하지 않도록 주의해야 한다. #3. 의미 있게 구분하라 연속된 숫자를 덧붙이거나 불용어를 추가하는 방식은 적절하지 못하다. #4. 발음하기 쉬운 이름을 사용하라 발음하기 어려운 이름은 토론하기 어렵다. #5. 검색하기 쉬운 이름을 사용하라 문자 하나를 사용하는 이름과 상수는 텍스트 코드에서 쉽게 눈에 띄지 않는다. 숫자나 영문 e 같..
앞으로 Clean Code를 틈틈이 읽으며 기록을 해보려 한다. Clean Code를 읽는 이유는 여러 가지가 있지만 가장 큰 이유는 더 나은 프로그래머가 되기 위해서 인 것 같다. 이 책을 읽어보며 좋은 코드가 무엇인지를 알고 좋은 코드를 작성하기 위해서 내가 해야 하는 것들에 대해서 알아가고 싶다. 기억에 남는 문장 코드를 작성할 때 나중에 손보겠다고 생각하는 경우가 있는데 나중은 결코 오지 않는다. (Leblanc's Law, 르블랑의 법칙) p.4 나쁜 코드는 개발 속도를 크게 떨어뜨린다. p.4 느낀 점 나쁜 코드가 쌓이면 쌓일수록 팀 생산성이 떨어지고, 생산성을 증가시키려고 인력을 투입하면 그 새 인력들은 기존 시스템 설계에 대한 조예가 깊지 않아 나쁜 코드를 더 많이 양산하게 된다고 한다. ..
