1. 암기강요를 안해야함

name space 를 어떻게 최소화하는가가 관건

6년 뒤의 내가 봐도 헷갈릴 정도면 문제가 있음.

과거의 나도 미래의 나도 사실상 타인임.


2. 재사용성이 좋아야함

물론 reusability 따위 다시 짤 수 없는 녀석들이나 떠드는 거라 하는 사람도 있고

money code 들은 의외로 그닥 재사용되지 않음.

따라서 어느정도는 자기만족이고, 노후 보장인데 이것도 cache 정책이랑 닿아있는 이야기임

'미래는 알 수 없다'가 통한단 말임.

적어도 자기가 짠 코드가 자기 코드들 안에서 유기적으로 재사용되어야 수정포인트가 줄어드는 부분은 있지.

이것도 결국 암기강요 이야기와 완전히 독립되진 않음.


3. 코드가 눈으로 보기에 깨끗해야함

대문자 난립한 코드는 시끄럽게 떠드는 코드들과 같음.

시선을 뺏는단 말이지.

snake 해라 snake

들여쓰기랑 탭, 괄호안에 띄우는것도 자기눈에 편안하게 맞추면 됨.

미적취향이 괴랄한 분들도 있는데...


4. 지나친 최적화는 독임

꼭 고성능이 필요하면 시궁창은 모듈로 분할해야됨


5. 길면 망함

하나의 모듈이 1000라인을 넘어가면 죄악임

하나의 함수가 30줄을 넘어가면 죄책감을 느껴야됨

한 눈에 보이게 짜야됨

블럭은 곧 anonymous function 이다.

이름이 필요없는 경우와 이름을 줘야되는 경우를 반대로 가는 사람들 많음.


6. 빌드가 귀찮으면 안됨

header only 좋다 이거야


7. 주석이 많으면 안됨

코드로 말하고, 어지간하면 따로 빼라 이거야


8. 다시 말하지만 줄이고 줄여야됨

구조가 비슷한 코드는 가능하면 합쳐라.

만들어 놓고 안쓰는 코드들은 다 따로 빼놨다가 좀 지워라.