-4, 5장- 주석, 형식 맞추기

들어가며

"나쁜 코드에 주석을 달지 마라. 새로 짜라"

주석이 필요한 상황이 오면 곰곰이 생각해보고 코드로 의도를 표현할 수 있지는 않을지 고민을 더 해봐야한다.

 

4 장

4-1. 주석은 나쁜 코드를 보완하지 못한다

당연히 깔끔하고 잘 표현되어진 코드가 복잡하고 어수선하며 주석이 많이 달린 코드보다 좋은 법이다.

 

4-2. 코드로 의도를 표현하라

의도를 최대한 코드로 나타내려고 노력하자. 주석으로 달려는 설명을 함수로 만들어 표현해도 충분하다.

 

4-3. 좋은 주석

법적인 내용을 담고 있는 주석

정보를 제공하는 주석

의도를 설명하는 주석

의미를 명료하게 밝히는 주석 (모호한 인수나 반환값에 대한)

결과를 경고하는 주석

TODO 주석

중요성을 강조하는 주석 (자칫 중요하지 않다고 여겨질뭔가에 대한 중요성 강조)

 

4-4. 나쁜 주석

허술한 코드를 지탱하고 있는, 합리화 하는 독백과 크게 다를빠 없는 주석들

코드 이해에 오해의 여지를 주는 주석

너무나도 당연한 단순한 내용을 담은 주석

공로를 돌리거나 저자를 표시하는 주석

주석으로 처리되어진 코드

너무 많은 정보를 담은 주석

 

함수나 변수로 표현할 수 있다면 주석을 달지않는 편이 좋다.

 

5 장

5장에는 형식에 맞춰 깔끔하게 코드를 짜야 한다고 주장하는 챕터이다.

개인 개발 중이라면 간단한 규칙을 정하고 그 규칙을 일관성있게 따라야 하고, 팀으로 일하는 중이라면 팀 내 합의되어진 규칙을 모두가 잘 따라야 한다는 내용을 담고 있다.

코드 역시 의사소통의 일환이고, 의사소통은 기본적인 소양이다.

적절한 행의 길이를 유지하고, 코드는 한 눈에 들어오는 것이 좋다.

보기 좋은 떡이 먹기도 좋은 것처럼, 팀으로 구성되어져 있다면 간단하고 깔끔하며 명료한 규칙을 정해 의사소통이 잘 되도록 하는 것이 실수도 줄이고 좋은 결과물을 낳을 수 있다고 생각한다.

 

마치며

최대한 코드에 내 목적을 다 담아보려고 노력해야하고, 피치못하게 주석을 달아야한다면 그 목적과 내용이 확실해야 한다.

가끔 기존 코드가 아까워서라던지, 나중에 쓸 수 있지 않을까해서 나도 내 코드를 주석처리 해둔 적이 있는데 생각해보면 git을 통해 추적해서 코드를 잃어버릴 일도 없고, 오히려 그냥 두면 나중에 오해를 발생시킬 여지가 있기 때문에 과감히 지웠어야했다.

 

좋은 형식이 마련되어 있으면 작업자가 편리하고, 그걸 보는 사람도 편리해진다.

이러한 것을 나는 이미 체감하고 있어서 그 중요함을 잘 느끼고 있다고 생각한다.