읽기 좋은 코드가 좋은 코드다.

읽기 좋은 코드가 좋은 코드다
Dev Rookie
Written By 최민수

1. 우리는 왜 좋은 코드를 작성해야 하는가?
2. 코드는 이해하기 쉬워야 한다.
3. 주석을 어떻게 달아야 할까?
4. 루프와 논리를 단순화하기
5. 그 외 많은 방법들..
6. 추천 도서 및 느낀점
목차

1.
1. 프로그램은 더 이상 혼자만의 전유물이 아니다.
2. 잘 작성된 코드는 탄력적이다.
3. 관리하기 용이하다.
4. 코드가 원래 목적한 제 기능으로 잘 동작한다.
1. 우리는 왜 좋은 코드를 작성해야 하는가?

코드는 이해하기 쉬워야 한다.

코드 가독성의 기본정리
- 코드는 다른 사람이 그것을 이해하는 데 들이는 시간을 최소화 하는 방식으로 작성되어야 한다.
- 여기서 ‘이해’란 자유롭게 코드를 수정하고, 버그를 짚어내고, 수정된 내용이 다른 부분의 코드와
어떻게 상호작용하는지 알 수 있어야 한다는 사실을 의미한다.

분량이 적으면 항상 더 좋은가?
- 코드는 다른 사람이 그것을 이해하는 데 들이는 시간을 최소화 하는 방식으로 작성되어야 한다.
- 여기서 ‘이해’란 자유롭게 코드를 수정하고, 버그를 짚어내고, 수정된 내용이 다른 부분의 코드와
어떻게 상호작용하는지 알 수 있어야 한다는 사실을 의미한다.

VS

주석을 어떻게 달아야 할까?

주석에 담아야 하는 대상
- 우리는 코드를 작성할 때 머릿속에 귀중한 정보가 있다.
- 그런데 다른 사람이 그 코드를 보면 그런 귀중한 정보는 없다.
- 그들이 가진 정보라곤 눈 앞에 있는 코드뿐이기에….
- 코드를 읽는 사람이 코드를 작성한 사람만큼
코드를 잘 이해할 수 있게 도울 수 있어야 한다.

설명하지 말아야 하는 것
- 코드에서 빠르게 유추할 수 있는 내용은 주석으로 달지 말자.
- 코드를 더 잘 이해할 수 있도록 도와주지 못하는 주석들은 가치가 없다.

나쁜 이름에 주석을 달지 말자.
- 대신 이름을 고치자.
- 이름이 ‘스스로 설명하는’ 느낌이 올 수 있도록 작성하자.
- 좋은 코드 > 나쁜 코드 + 좋은 주석

VS

생각을 기록하라.
- 좋은 주석은 자신의 생각을 기록하는 것만으로도 탄생할 수 있다.
- 코딩할 때 생각했던 중요한 생각을 기록하면 된다.
- 마치 영화 감독의 설명처럼…

코드에 있는 결함을 설명하라.
- 코드는 지속적으로 진화하며, 그러는 과정 중에 버그를 갖게 될 수 밖에 없다.
- 그것을 두려워하거나, 부끄러워하지 말자.
- 작성하는 코드의 내용이 훗날 수정될 것이라 생각이 들면, 그러한 것을 주석으로
남기자.

상수에 대한 설명
- 상수를 정의할 때는 그것이 왜 특정한 값을 갖게 되는지 사연이 존재
- 이러한 상수값을 선택한 사람이 자신이 생각하는 이유와 경험을 주석으로 달아
놓으면 다른 사람들이 코드를 이해하기 더욱 쉬워질 것이다.
- SECONDS_PER_DAY 와 같은 이름이 명확한 상수는 주석이 없어도 된다.
주석은 어떻게 달아야 할까?

코드를 읽는 사람의 입장이 되어보자.
- 이 책은 코드를 처음으로 읽는 외부인의 입장에 자기 자신을 놓는 기법을 다루고
있다.
- 나올 것 같은 질문 예측하기
- 사람들이 쉽게 빠질 것 같은 함정을 경고하라.
- 요약 주석을 작성하자
주석은 어떻게 달아야 할까?

- 모호한 대명사는 피하라
VS
명확하고 간결한 주석달기

- 주석을 간결하게 하라.
- 엉터리 문장을 다듬어라.
- 코드의 의도를 명시하라.
VS

- 정보 축약형 단어를 사용하라
VS

루프와 논리를 단순화하기

흐름을 제어하는 조건과 루프 그리고 여타 요소를 최대한 자연스럽게 만들도록 노력하자.
코드를 읽다가 다시 되돌아가서 코드를 읽지 않아도 되게끔 만들어야 한다.

어떤 것이 더 읽기 편하게 느껴지시나요?

이 책에서 말하는 유용한 규칙은 다음과 같습니다.
유동적인 값인 변수보단 고정적인 더 안정적인 값을 비교값에 사용되게 하는 것입니다.

if / else 블록의 순서
- 부정이 아닌 긍정을 다루자. 즉, if(!debug)가 아닌 if(debug)를 선호하자.
- 간단한 것을 먼저 처리하자. 이렇게 하면 동시에 같은 화면에 if와 else 구문을
나타낼 수도 있다. 두 개의 주문을 동시에 보는 게 더 좋다.
- 더 흥미롭고, 확실한 것을 먼저 다루어라.

expand_all이 뭘까..?

분홍색 코끼리를 상상하지 마세요.

(삼항 연산자로 알려진) ? : 를 이용하는 조건문 표현
VS
줄 수를 최소화하는 일보다 다른 사람이 코드를 읽고 이해하는 데 걸리는 시간을
최소화하는 일이 더 중요하다.

do/while 루프를 피하라.

“내 경험으로 에러와 혼동의 원인은 do문에 있다. 그래서 나는 조건이 눈에 뜨이는 곳에
미리 나타나도록 만드는 것을 선호한다. 결과적으로 나는 do문을 피하는 경향이 있다.”
- 반얀 스트라우스트럽 曰

함수 중간에서 반환하기
- 반환 포인트를 하나만 두려는 건 함수의 끝부분에서 실행되는 클린업 코드의
호출을 보장하려는 의도다.

중첩을 최소화 할 수 있다.

수정해야 하는 상황이라면, 여러분의
코드를 새로운 관점에서 바라보라.
뒤로 한걸음 물러서서 코드 전체를 보라.
* 같은 방식으로 루프 내부에 있는 중첩도
제거 할 수 있다.

거대한 표현을 잘게 쪼개기

설명 변수를 사용하자.
- 커다란 표현을 쪼개는 가장 쉬운 방법은 작은 하위표현을 담을 추가변수를
만드는 것이다.


요약 변수를 사용하자.
- 커다란 코드의 덩어리를 짧은 이름으로 대체하여 더 쉽게 관리하고 파악하는
목적을 가진 변수를 요약 변수라고 한다.
- 요약 변수를 사용할 경우, 읽는 사람이 ‘이것이 바로 이 함수에서 생각해야 하는
주된 개념이군’ 이라고 생각할 수 있게 한다.




드모르간의 법칙 사용하기
- 회로나 논리 수업에서 배웠던 기억이 나는 법칙…
- 기억이 안난다면 이것만 기억하자.
- not을 분배하고 and/or를 바꿔라.

쇼트 서킷 논리(Short-Curcuit Logic) 오용 말기
- 대부분의 프로그래밍 언어에서 불리언 연산은 쇼트 서킷 평가를 수행한다.
- ex) if (a || b) 에서 a가 참이면 b는 평가하지 않는다.

쇼트 서킷 논리(Short-Curcuit Logic) 오용 말기
VS
영리하게 작성된 코드에 유의하라.
나중에 다른 사람이 읽으면 그런 코드가 종종 혼란을 초래한다.

예제

더 우아한 접근방법 발견하기

반대되는 방법으로 한번 생각해보자.
- 다른 범위가 이 범위 시작보다 전에 끝난다.
- 다른 범위가 이 범위가 끝난 후에 시작된다.

표현을 단순화하는 다른 창의적인 방법들

1. 표면적인 수준에서의 개선
- 이름 짓기
- 설명문
- 미학
2. 코드 재작성하기
- 상관없는 하위문제 추출하기
- 한 번에 하나씩
- 생각을 코드로 만들기
- 코드 분량 줄이기
3. 선택된 주제들
- 테스트와 가독성
- 등등..
그 외 많은 방법들..

클린 코드
Java 언어 기반(예제)
저자 로버트 C. 마틴
추천도서 및 느낀점

1. 프로그래밍이 언어라는 관점에서 다시 한번 생각하는 계기가 되었습니다.
2. 코드를 작성할 때 다른 사람에 대한 생각도 꾸준히 해야한다는 것을 느꼈습니다.
3. 다른사람에게 내가 배운 것을 전달한다는 것이 얼마나 어려운 것인지 다시 한번 느끼게
되었습니다.
추천도서 및 느낀점

읽기 좋은 코드가 좋은 코드다.

More Related Content

Similar to 읽기 좋은 코드가 좋은 코드다.

More from TonyCms

읽기 좋은 코드가 좋은 코드다.