본문 바로가기
BackEnd/Clean Code

전반적인 코드에서 배제할 것

by 12312121 2022. 1. 4.

1. 코드의 간결성은 유지하되 함축성을 배제하라

함축성은 읽고 이해할때 읽는 사람에게 어떤 지식 가지고 있다고 가정한다.

이것은 시간이 지남에 따라 인간의 기억력에 큰 부담을 주고, 처음부터 다시 읽어야 하는 상황을 만든다

처음 보는 사람조차 이해할 수 있게 대명사를 배제하고, 코드상의 역할과 동일한 이름을 쓰고, 다른 변수간의 관계가 바로 보이는 이름을 써라

2. 오해의 가능성을 피하라

예를 들어 hp는 hypotenuse(빗변)의 휼륭한 약어처럼 보일지라도 회사명 hp와 충분히 헷갈릴 가능성이 있다

특히 대문자 O와 소문자 l은 숫자 0과 대문자 I와의 혼동을 일으킨다

또한 유사한 개념은 유사한 표기법으로 써서 이해 시의 정보로 쓰일 수도 있는데, 전혀 다른 개념을 유사하게 써서 오해를 일으키는 것도 안된다.

3. 연속적인 숫자 사용 (a1, a2, ... aN)을 배제하라

이것은 아무런 정보도 제공하지 못하고 이름은 적을 때는 편하더라도, 작성 시간과 읽는 총 시간을 비교하면, 수십번 이전 코드를 다시 되읽으므로 후자가 10배 이상 더 크다. 따라서 이건 사서 고생하는 셈이다

4. 발음하기 어려운 이름을 배제하라

예를들어 genymdhms(=generate date, year, month, day, hour, minute, second)라는 변수가 있다면 코드 리뷰 시에 젠 와이 엠 디 에이치 엠 에스라고 말하며 굉장히 우스꽝스럽고 어떤 사람은 제님드흠스라고 불러서 다른 사람이 못 알아들을 수도 있다. 프로그래밍은 사회 활동이다.

5. 헝가리안식 표기를 배제하라

IDE가 발달 하지않던 시절에, IDE로 변수의 자료형을 알아낼 수 없을때 해결하기 위해 만들어진 표기법이다. 현대에는 불필요하다

6. 기억력 자랑을 배제해라

또한 반복문의 반복횟수를 세는 변수로 i, j, k는 전통적으로 사용해와서 써도 괜찮아도, a, b, c, d ... 이렇게 계속 쓰는건 다른 사람 입장에서 의미를 알아볼 수도, 본인도 얼마 안지나서 잊기 때문에 배제해야한다

7. 기발한 이름을 배제하라.

유머코드가 비슷하거나 농담을 기억하는 동안만 알 수 있기 때문에 안좋다 예를들어 kill()이 있다

8. 유연성을 배제하라

한 단어를 두가지 목적으로 사용하지마라. 만약 사용하려 한다면 그건 의미를 확장시킨 것이다.

예를들어 무언갈 만드는 메서드의 이름이 add인데
무언가에 추가할 메서드를 만들 상황에서 일관성을 지키기 위해 add를 쓰는건 바람직하지 않다. 맥락이 다르기 때문이다.

'BackEnd > Clean Code' 카테고리의 다른 글

Clean Code : 추상화  (0) 2022.01.18
Clean Code : 주석2  (0) 2022.01.12
Clean Code : 주석  (0) 2022.01.12
Clean Code : 함수  (0) 2022.01.11
전반적인 코드 작성 시에 써야할 것  (0) 2022.01.05

댓글