여전히 회복이 덜되었다. 걸린채로 하루종일 일하는건 확실히 쉽지 않은가보다...그래도 뒤쳐진것 다 따라잡아가는 중.
Code Format?이었을것 같다. Naming Convention 이야기일 수도 있겠지만 그보다는 들여쓰기, 어디에든 들어갈 수 있는 코드들을 어디에 배치해야 하는지, 괄호의 생략 여부 등에 대한 내용이다. 사실 이 장의 내용은 요즘 IDE들이 자동으로 고쳐주는 경우가 매우 많다. 책에서도 언급한다. 그래도 이왕이면 손에 익혀두는게 나쁘지 않을 듯.

프로그래머라면 형식을 깔끔하게 맞춰 코드를 짜야 한다. ... 간단한 규칙을 정하고 그 규칙을 착실히 따라야 한다.
잘 훈련된 부대는 제식훈련부터 다르다. 열병식의 모습도 멋있게 보인다. 물론 군인은 슬프다. 잘 운영되는 팀의 코드는 것보기에도 정렬되어 있다. 내용을 읽기 전부터 어디에 무엇이 있는지 눈에 보이는 정도이다.
코드 형식은 의사소통의 일환이다. 의사소통은 전문 개발자의 일차적인 의무다.
오늘 구현한 기능이 다음 버전에서 바뀔 확률은 아주 높다. 그런데 오늘 구현한 코드의 가독성은 앞으로 바뀔 코드의 품질에 지대한 영향을 미친다.
코드 형식은 가독성에 지대한 영향을 미치고, 이는 앞으로 코드 발전에 큰 영향을 미치는 코드를 사용하는 전문가의 의사소통 능력의 일환이다.
500줄을 넘지 않고 대부분 200줄 정도인 파일로도 커다란 시스템을 구축할 수 있다. 일반적으로 큰 파일보다 작은 파일이 이해하기 쉽다.
신문 기사처럼 작성하라
개념은 빈 행으로 분리하라
package, import, class가 나오는 줄들을 각각 분리해준다.연관성이 높은 코드는 세로로 가깝게 배치한다.
수직 거리
protected를 피하자.assertTrue, assertFalse 등은 가까이 배치되어 있다.세로 순서
프로그래머는 짧은 행을 선호한다.
;를 덧붙여 블록이 끝났음을 알려주자.은 지키자. 한 소스파일의 형식을 다른곳에서도 발견해야 신뢰감을 보여줄 수 있다.
정말 사소하지만 중요한 내용이 공백의 처리가 아닌가 싶다. 지금도 여러 코드들을 보면 함수, 메서드 이름 뒤에 공백 쓰고 괄호를 넣으면서 +, - 앞뒤에는 공백이 빠지는 코드가 많다. 심지어 이들은 IDE들도 잡아준다! 나름 스타 높은 레포를 클론해도 Pycharm이나 IDEA로 열어보면 노란줄(문법적 오류가 아닌 형식상 비권장) 투성이이다. 그들은 이 노란줄이 눈에 밟히지 않았던 것일까?
그러니 사실 요즘엔 조금만 신경써도 지킬 수 있는게 Code Formatting이다. 특히 코딩을 배우고 있는 입장이라면, IDE가 나에게 주는 신호를 무시하지 말자. 그 신호를 지키면 적당히 이쁜 코드는 얼마든지 만들 수 있고, 그런 코드를 작성해야 내 코드가 좀더 잘 읽히며, 그래야 내가 무슨짓을 한건지를 나중에라도 알아볼 수 있다. 그리고 부끄러워하고, 더 나아가라! 어차피 옛날 코드는 전부 끔찍한 괴물이니까, 과거의 실수를 반복하지만 않으면 된다!