코드 자체만으로 의도를 표현하는 게 좋다. - 주석을 안 좋게 보는 이유: 코드를 고칠 때 함께 고치지 않으면 틀린 설명이 된다. --> 나쁜 코드에 주석 달아서 그럴싸해보이게 하지 말고 코드를 가독성있게 다시 짜라! 좋은 주석? - 법적인 주석 (copyright...) - 정보를 제공하는 주석 (ex. 어떤 인스턴스인지 / 정규 표현식 설명) --> 함수나 클래스로 분리해 주석을 없애는 게 더 낫다 - 의미를 명료하게 밝히는 주석 (ex. 모호한 인수나 리턴값) --> 명확한 표현을 써서 만들면 좋지만 라이브러리 코드처럼 변경이 안되는 경우 - 결과를 경고하는 주석 - TODO 주석 - 중요성을 강조하는 주석 (남들이 대수롭지 않게 생각할 것 같은 부분인데 사실 그러면 안되는 포인트인 곳들) 나쁜 주..
함수는 작게, 최대로 작게! - 들여쓰기 1 ~ 2단, 중첩 if / while은 최대한 제거하기 함수 하나에 하나의 기능만 넣자. - 판별: 함수 내에서 다른 함수로 추출이 가능한 코드가 있는가? 코드 아래로 내려갈수록 추상화 수준이 낮아지도록 함수를 배치 switch문 많이 쓰지 않기 서술적인 이름 사용 - 이름으로 기능을 유추하기 쉽도록 (ex. testableHTML -> setupTeatdownIncluder.render) 함수 인수 - 0개가 이상적, 최대 2개, 3개는 지양 - 1개 - 인수에게 질문 던지기 (boolean fileExist("MyFile")) - 인수를 반환 후 변환하는 함수 - flag 인수 - 제발 하지 마라, True와 False 결과에 해당하는 코드를 두 함수로 쪼개..
의도를 분명하게 밝혀라 - 이름을 대강 지어두고 주석으로 설명하는 것보다는 어떤 의도를 가지고 변수를 선언했는지가 이름에 드러나도록 - 코드의 "함축성": 코드의 맥락이 보이도록 (읽는 사람에게 정보 전달) 그릇된 정보를 피하라 - 정확한 정보 전달이 가능한 이름 선언 - 흡사한 이름 사용하지 않기 (ex. XYXControllerForEfficientHandlingOfStrings, XYZControllerForEfficientStorageOfStrings) 의미 있게 구분하라 - a1, a2, a3 같은 이름 말고 의도가 드러나는 이름을 사용 - 불용어 줄이기 (ex. NameString > Name, CustomerObject > Customer) 발음하기 쉬운 이름을 사용하라 검색하기 쉬운 이름을..
코드를 최대한 깨끗하게 유지하는 습관 들이기 읽기 쉬운 코드 짜기 - 코드가 복잡해지면 유지보수에 필요한 시간이 늘어난다. 깨끗한 코드는 뭘까? 1. 비야네 스트롭스투룹 논리가 간단한 코드 --> 한 가지에 집중하는 코드 2. 그래디 부치 단순하고 직접적인 코드 --> 가독성이 중요 3. "큰" 데이브 토마스 다른 사람이 코치기 쉬운 코드, 테스트 코드 작성 4. 마이클 페더스 주의 깊게 짠 코드 --> 깔끔하고 단정하다 5. 론 제프리스 중복은 낮추고 표현력은 높인다, 간단한 추상화 6. 워드 커닝햄 코드를 읽는 사람의 짐작대로 수행하는 코드 '읽기 좋은 코드가 좋은 코드다'라는 책도 있을 정도로 가독성은 코드를 짜는 사람에게도, 확인하는 사람에게도 중요한 것 같다. 메서드 하나를 짜더라도 최대한 하나..
