네이밍
Convention
- snake_case: Python, Ruby
- camelCase: Java, JS
- pascalCase: Class Naming
- kebab-case: HTML Element
변수와 상수
명사 및 형용사 형태
함수와 메서드
동사 및 형용사 형태
public sendData(){}
def input_is_valid():클래스
명사 형태
public class Client{}
class RequestBody:tips
- 구체적, 명시적으로 작성
- 애매한 표현 제거
짧고 직관적인 네이밍이 이상적
주석&포맷팅
주석
- 법적인 정보를 담을 때
- 의도를 명확하게 설명할 때
- 중요성을 강조할 때
- 결과를 경고할 때
관용적으로 사용되는 키워드
# TODO: 당장은 아니지만 다음에 해야 할 때
# FIXME: 치명적인 에러를 발생하는 코드는 아니지만 수정해야 할 때
# XXX: 더 생각해볼 필요가 있을 때포맷팅
Vertical Formatting
- 한 파일에 모든 클래스를 넣어놓지 말고 파일 별로 나눠서 관리하기
- 다른 개념의 코드는 Spacing으로 분리하기
- 비슷한 개념의 코드는 붙여서 사용하기
Horizontal Formatting
- 한 줄에 코드를 다 넣기보단 변수 활용해 가독성 높이기
- 네이밍 잘해서 길이 줄이기(간결한 네이밍)
함수
하나의 역할만 맡기기(SRP)
반복하지 않기(Don't Repeat Yourself)
파라미터 수는 적게 유지
파라미터가 많게 느껴진다면 하나의 클래스로 만들어 전달하자
객체지향적으로 클래스가 생서되지 않는다면 함수가 객체의 행위를 대표하지 않는 경우일 수 있다.
사이드 이펙트를 잘 핸들링하자
사이드 이팩트: 함수가 실행됐을 때 함수 이외의 어떤 것들이 변화를 주는 것
- 잘 핸들링하는 법
- 적절한 네이밍
- 사이드 이팩트가 있는 부분과 없는 부분을 나눠서 관리
- update 사용보다는 순수 함수 형태로 사용하는 것이 더 직관적
클래스
단일 책임 원칙(SRP)
하나의 클래스는 하나의 책임만을 가지도록 선언
응집도를 높이기
응집도: 클래스의 변수와 메서드들이 얼마나 유기적으로 엮여있는 지를 나타내는 지표
개방 폐쇠 원칙(OCP)
새 기능을 추가하거나 기존 기능을 변경할 때, 코드 변경을 최소화하는 것이 중요
구체 클래스에 의존하지 않고 추상 클래스(인터페이스)에 의존하도록 코드를 짜기
에러 핸들링
오류 코드보다는 예외 사용
VALUE_ERROR="VALUE_ERROR" # 오류 코드
try:
...
except ValueError as e:
...예외 클래스 잘 정의하기
built in Exception을 잘 활용하고 직접 Custom Exception을 만들어 사용하는 것도 좋음
에러 로직 잘 처리하기
에러 핸들링을 모을 수 있다면 한번에 처리하기
같은 수준의 깊이에서 여러 에러가 처리된다면 한 단계 높은 수준에서 한번에 처리하는 것이 더욱 명시적으로 보인다.
절대 에러 핸들링에 비즈니스 로직을 넣지 말 것 -> 유지보수 망함
코드 indent 줄이기(Guard Clausing, Polymorphism)
if-else 문이 꼬리에 꼬리를 물게 되면 indentation이 많아져 어느 블럭까지가 현재 작성하고 있는 블럭인지 알기 어려워진다.
Guard clause
fail이 되는 로직을 위로 넣어 미리 제거하기!
if-raise를 통해 에러를 발생시키거나 if-continue를 통해 지나가는 것 또한 방법임
Polymorphism
현실 세계의 객체를 표현하는 클래스를 남발하지 말고 상위 개념으로 묶어 상속을 사용하면 중복되는 행위에 대해서 추상 메서드를 두어 개별 구현할 수 있다.
이렇게 개별 구현된 메서드를 이용하면 모두 같은 이름의 메서드를 공유하므로 캐스팅이나 제너릭을 이용해 상위 객체 클래스를 이용해 일괄적으로 메서드를 실행시킬 수 있다.
