# 작게 만들어라
# 한 가지만 해라
# 함수 당 추상화 수준은 하나로
# Switch 문
# 서술적인 이름을 사용하라
# 함수 인수
# 부수 효과를 일으키지 마라
# 명령과 조회를 분리하라
# 오류 코드보다 예외를 사용하라
# 반복하지 마라
# 구조적 프로그래밍
작게 만들어라 ... 당연하다. 가능하다면 ...
한 가지만 해라 ... 당연하다. 여러가지를 한다면, 그리고 하나의 함수가 기능이 많다면 그만큼 관리하기 어렵고 관계가 너무 많아진다. 함수가 가진 부담이 많아짐.
함수 당 추상화 수준은 하나로 ? TODO(주석) 읽는 것처럼 함수가 스스로 세부 사항을 포함시키지 않도록(되도록이면 ... ex: 인수를 넣는 것) 노력하라.
Switch 문 ... 되도록이면 한가지 기능을 하되 유해한 구문 제거
서술적적인 이름을 사용하라 ... 이책에서 줄창 강조하는 내용
함수 인수 ... 인수가 여러개라면 해당 메소드나 함수를 사용할때 오해나 분석해야 되는 시간이 많아진다. 되도록이면 인자가 없되, 있어도 1개에서 2개선에서 하도록 함. Flag 를 사용하는 것은 피하고 3항 이상은 만들지 마라고 한다. 흠... 저번에 인자 6개짜릴 만든적이 있어서 좀 반성해야 되는 부분 ... 그리고 함수는 되도록 동사 + 명사 형태로 하되, write(name)과 같이 사용자가 직관적으로 알 수 있도록 하면 더욱 좋다고 한다.
부수 효과를 일으키지 마라 ... 하나의 함수가 하나의 Action을 해야지 만약 저장하는 함수가 저장기능을 수행하고 파일을 삭제하는 일까지 해버리는 일은 하지 말라는 말. 함수를 사용하는 사람이 자신이 의도하지 않은 파일도 사라질 수 있으므로 ...
명령과 조회를 분리하라 ... isSuccess 같이 조회 기능을 하는 함수와 order 같이 명령하는 함수는 분리해서 사용하라고 한다.
오류 코드보다 예외를 사용하라 ... boolean isSuccess(상태) 보다 ... 그냥 예외를 통해서 처리하는게 원래 코드와 분리되어 코드가 깔끔해진다고 한다.
반복하지 마라 ... "하위 루틴을 발명한 이래로 소프트웨어 개발에서 지금까지 일어난 혁신은 소스 코드에서 중복을 제거하려는 지속적인 노력으로 보인다"
구조적 프로그래밍 ... 음 ... 이건 패쓰 ?
마무리로 ... "프로그래밍의 기술은 언제나 언어 설계의 기술이다"
※ 위 내용은 "Clean Code" 책에서 내용을 발췌하였습니다.