코드를 작성하면서 굳이 고쳐야 한다거나, 집중해서 신경쓰지 않았던 것이 있다. 바로 형식 맞추기. 누구나 코딩을 한다면 굳이 크게 신경쓰지 않고, 처음의 그 습관을 그대로 가져가는 경우가 많을 것 같다. 클린 코드에서 굳이 한 챕터를 '형식 맞추기'로 꺼낼 정도로 의미가 있나 싶기도 했는데 읽어보니 역시 그렇구나, 하고 고갤 끄덕이게 됐다. 한 파일은 200줄 정도로 하는 것이 바람직하다. 가로로도 저자 개인적으로는 120자 정도로 행 길이를 제한한다고 한다. 개념은 행(띄어쓰기)으로 분리해야 한다. 서로 밀접한 개념의 경우는 가까이 둔다. 변수는 사용하는 위치에 최대한 가까이 선언하고, 인스턴스 변수들은 메서드와 섞이지 않게 한쪽으로 잘 정리한다.(보통은 위쪽) 한 함수가 다른 함수를 호출할 때도 가까..
나는 평소에 협업을 하기 위해서는 내 코드를 보기 편하게 만들 필요가 있다고 생각했고, 그래서 주석을 자주 활용하곤 했는데 이 부분을 읽으면서 그게 과연 맞는 것일까 하는 생각이 들었다. 저자는 주석을 다는 것을 지양해야 한다고 말하고 있다. 주석을 다는 것보다 코드로 충분히 표현할 수 있는 방법을 찾아야 한다고. 우리의 일은 코드를 짜는 것이지, 주석을 짜는 것이 아니기 때문에 코드를 작성하고 수정하다보면 주석이 그 자체의 의미를 잃어버릴 수 있기 때문이다. 예전의 코드는 수정됐지만, 주석은 업데이트되지 못하고 예전의 상태를 유지하는 걸 (짧은 경험이지만) 많이 봐왔고, 느꼈다. 결국 주석은 거짓이 되어버리고, 주석을 단 의미가 사라진 것이다. 그럼에도 저자가 좋은 주석이라고 생각하는 몇 가지가 있었다..
함수를 만드는 첫번째 규칙, 작게 만들어라. 두번째 규칙, 함수를 한 가지를 잘 하도록 만든다. = 작게 만든다. = 들여쓰기를 많이 하지 않는다. 세번째 규칙, 추상화 수준을 동일하게 해라. 네번째 규칙, 위에서 아래로, 이야기를 읽듯이 흘러가게 해라. 다섯번째 규칙, 이름을 붙일 때, 서술하듯이 붙인다. 여섯번째 규칙, 가능한 인수의 개수를 줄여라. (객체 이용) 일곱번째 규칙, 오류코드보다 예외를 사용해라. 여덟번째 규칙, 반복을 피해라. 저자의 함수 짜는 법 1. 우선 작성한다. (단위 테스트 케이스도 작성한다.) 2. 코드를 다듬고, 함수를 만들고, 이름을 바꾸고, 중복을 제거한다. 메서드를 줄이고 순서를 바꾼다. 클래스를 쪼개기도 한다. (이 과정에서 단위 테스트는 항상 통과한다.)
개인적으로 코드를 작성할 때 가장 기본이 되는 건 의미 있는 이름을 붙여주는 것이라고 생각한다. 아무리 간단한 코드를 짜더라도 그냥 a, b, 혹은 list1, temp 이런 이름을 붙이는 걸 지양하고 있다. 의미 있는 이름을 붙이려면 어떻게 해야 할까. 이름을 붙이는 이유는 그 역할을 명확히 하기 위해서이다. 왜 존재하고, 어떤 기능을 하는지 등을 명확하게 나타내기 위해서이다. 그렇기 때문에 이름을 붙일 때에는 역할을 명확하게 밝힐 수 있는 이름을 붙이는 것이 좋다. 클린 코드 2장의 내용을 간단하게 요약해보자면 아래와 같다. 1. 유사한 개념별로 유사한 표기법을 사용한다.(= 한 개념에는 하나의 표기법을.) 2. 비슷한 이름을 사용하지 않도록 한다. 3. 코드는 다른 개발자들과 의사소통하기 위한 도구..
협업을 위해서나 나를 위해서나 깨끗하게 코드를 쓰는 것이 중요하다고 생각해서 클린코드를 읽고 있는데 정리가 필요할 것 같아서 간단히 내용을 요약한다. 최소한의 내용만을 담고 있으니, 더 많은 내용을 원하는 분은 책을 사서 읽으셨으면 좋겠다. 1. 깨끗한 코드가 왜 중요한가? 코드가 사라질거라고 하는 사람들도 있지만, (저자가 생각하기엔) 앞으로 코드가 사라질 일은 없다. 요구사항은 사람으로부터 나오고, 그런 사람들이 개떡같이 말해도 찰떡같이 동작하는 기계는 나오기 어렵기 때문이다. 그럼 앞으로도 코드를 계속 작성해야하는데, 왜 코드를 깨끗하게 작성해야할까? 기한이 촉박하다고, 제대로 짤 시간이 없다고 생각해서 코드를 먼저 작성하고 나중에 정리해야겠다고 다짐하지만 결코 그 나중은 오지 않는다.(르블랑의 법..