네이밍
•
Convention
◦
snake_case : Python, Ruby 등에서 권장
◦
camelCase : Java, Javascript 등에서 권장
◦
PascalCase : 대부분의 프로그래밍 언어에서 클래스를 네이밍할 때 사용함
◦
kebab-case : HTML Elemnet를 표현할 때 사용
•
변수와 상수
◦
일반적으로 변수와 상수 네이밍 시에는 명사 혹은 형용사 구문 형태로
◦
ex) user_data, is_valid 등
•
함수와 메서드
◦
일반적으로 함수와 메서드를 네이밍할 때는 동사 혹은 형용사 구문 형태로
◦
ex) send_data, input_is_valid 등
•
클래스
◦
일반적으로 클래스 이름을 네이밍할 때는 명사 구문 형태로
◦
ex) Client, RequestBody 등
•
Tips
◦
구체적이고 명시적으로 적을 것
▪
너무 간략화된 네이밍 금지
▪
흐름을 쉽게 파악할 수 있게끔 네이밍
◦
불필요한 표현은 제거할 것
▪
불필요한 관사는 피할것
▪
변수명에 타입을 부가적으로 표현하는 등의 행동은 피할것
주석, 포맷팅
•
모든 내용을 주석으로 넣게될 경우 코드가 지저분해질 수 있다. 대부분은 좋은 naming으로 충분히 해결 가능
•
네이밍으로 표현할 수 없는 영역은 주석으로 표현해주면 됨
◦
법적인 정보를 담을 때
◦
의도를 명확하게 설명할 때
◦
중요성을 강조할 때
◦
결과를 경고할 때
•
관용적으로 사용되는 키워드
◦
TODO : 당장은 아니지만 다음에 해야할 때
◦
FIXME : 치명적인 에러를 발생하는 코드는 아니지만 수정해야 할 때
◦
XXX : 더 생각해볼 필요가 있을 때
•
포맷팅
◦
Vertical Formatting
▪
한 파일에 코드를 다 넣지말고 설계에 맞춰 파일을 나눠서 사용
# as-is
# store.py에 전부 있음
class FruitsStore:
...
class ComputerStore:
...
# to-be
# fruit_store.py
class FruitsStore:
...
# computer_store.py
class ComputerStore:
...
Plain Text
복사
▪
다른 개념의 코드는 공백으로 분리
▪
비슷한 개념의 코드는 붙여서 사용
◦
Horizontal Formatting
▪
한 줄에 코드를 다 넣기보단 변수등을 활용해서 가독성을 높이기
#as-is
product_list.extend([Product("모니터"), Product("키보드"), Product("노트북")])
#to-be
items = [Product("모니터"), Product("키보드"), Product("노트북")]
product_list.extend(items)
Plain Text
복사
▪
네이밍 잘해서 길이 줄이기
#as-is
user_with_name_and_email = User("그랩", "grab@world.com")
#to-be
user = User("그랩", "grab@world.com")
Plain Text
복사
함수
•
함수의 역할은 하나만 할 수 있도록 하자
◦
함수 하나는 하나의 기능?을 하도록?
•
반복하지 말자 - DRY
◦
관심사를 잘 분리하고 의존성을 줄이기 위해 반복되는 코드를 하나의 함수로
•
파라미터의 수는 적게 유지하자
◦
없는 게 best, 최대 1개까지
•
사이드 이펙트를 잘 핸들링하자
◦
함수가 실행됐을 때, 함수 이외의 어떤 것들에 변화를 주는 것
◦
객체의 값이 변한다거나 DB session에 변화를 주는 것
클래스
•
단일 책임 원칙 지키기
◦
하나의 클래스는 하나의 책임만 가지도록
•
응집도를 높이자
•
변경하기 쉽게 만들자 - 다형성
◦
확장엔 열려있고 변경엔 닫혀있게끔
◦
일반적으로 클래스는 구현과 추상으로 나뉘게 되는데, 구현에는 실제 동작하는 구체적인 코드가 추상은 인터페이스나 추상 클래스처럼 기능을 개념화한 코드가
◦
추상화를 해두고 구체 클래스에 의존하지 않고 추상 클래스에 의존하도록 코드를 짜는 것이 중요
에러 핸들링
•
오류 코드보다는 예외 사용하기
◦
오류 코드를 사용하게 되면 상단에 오류인지 확인하는 부가 로직이 필요함, 오류의 범주에 들어가지 않은 상태를 나타내는 것이 아니라면 예외로 명시적으로 에러 처리 표현
•
예외 클래스 잘 정의하기
◦
Raise Exception으로 하기보단 Base Exception을 상속해서 Error Handling하는데, 내장된 built in Exception 즉 각 상황에 맞는 Exception을 갖다 써라
•
에러 핸들링 잘하기
◦
에러를 포착했다면 잘 핸들링해주어야 함
▪
catch 문에 pass같은걸 쓰지마라 왜 쓰냐?
▪
로그만 넘긴다고 끝이 아니다, 로그가 발생하고 추가적인 처리가 필요하다면 해주어라
▪
로그도 찍어주고, 예측 불가능한 외부 I/O 이슈면 내 이메일에 알리기
▪
만약 이 함수를 호출하는 다른 함수에서 추가로 처리해야한다면 에러를 올려주기
▪
에러가 발생하더라도 항상 실행되어야 하는 로직이 있다면 finally 문을 넣어줘라
◦
에러 핸들링을 모을 수 있다면 한 곳으로 모아라
▪
같은 수준의 로직을 처리한다면 한 곳으로 모아서 처리
▪
트랜잭션과 연관지어 생각해서 로직을 분리
코드 indent 줄이기
•
Guard Clasuing
◦
중첩 구문의 경우, 범위를 점차 좁혀나가게끔 예외를 발생시키는게 이해하기에 좋다
•
Polymophism
◦
다형성을 사용하는게 코드 인덴트를 줄이기 좋다
