- 코드를 봤을 때 깔끔하고 일관적이면 전문가가 짰다는 인상을 준다. 그렇지 않다면 무성의하게 짰을 거라고 생각한다.
- 코드 형식은 의사소통의 일환.
- 계속해서 변경되는 코드는 가독성이 유지보수 용이성과 확장성에 영향을 미친다.
- 유지보수 과정에서 다른 사람이 코드를 고쳐야 될 경우, 형식이 맞춰져 있으면 코드를 읽기가 쉬워진다.
- 코드 형식을 맞추기 위해 규칙을을 정하고 그 규칙을 따라야 한다.
- 소스 코드의 길이?
- 클래스의 크기는 500줄을 넘지 않고 200줄 정도 (주식차트 그림)
- 한 클래스가 너무 크면 하나의 기능만 하고 있는 게 아닐수도 있다
- 신문 기사처럼 작성하라
- 소스 파일 이름은 간단하면서도 설명이 가능하게 짓는다.
- 소스 파일 첫부분은 고차원 개념과 알고리즘, 아래로 갈수록 저차원 함수와 세부 내역 (initialize 함수같은 것도 아래에 배치하면 좋을 듯)
- 개념은 빈 행으로 분리
- 일련의 행 묶음(중괄호 시작과 끝 같은)은 완결된 생각 하나
- 빈 행은 새로운 개념을 시작한다는 시각적 단서
- 패키지 선언, import 문, 각 함수 사이에 빈 행을 넣어서 분리
- 서로 밀접한 코드 행은 세로로 가까이 놓여야 한다. (세로밀집도)
- 변수끼리, 메서드끼리 모아놓아라 (변수 중간에 주석을 넣어서 떨어뜨려 놓지 말아라)
- 서로 밀접한 개념은 한 파일에 속해야 한다. (수직거리)
- 코드 조각을 찾기 위해 이 파일 저 파일 찾아다니면 시간과 노력 소모
- protected 변수를 피해야 한다.
- 변수 선언
- 지역 변수는 함수의 맨 처음에
- 인스턴스 변수는 클래스 맨 처음에
- 루프 제어 변수 (i,j같은) 는 루프 문 내부에
- 종속 함수
- 한 함수가 다른 함수를 호출한다면 가까이 배치하고 호출하는 함수가 호출되는 함수보다 먼저 배치
- 개념적 유사성
- 친화도가 높은 코드일수록 코드를 가까이 배치
- 종속함수, 변수와 그 변수를 사용하는 함수가 예로 있다.
- 명명법이 똑같고 기본 기능이 유사한 함수들 (assertXXX, setXXX, getXXX)
- 짧은 행이 바람직. 120자 정도
- 가로는 공백을 사용해서 밀접한 개념과 느슨한 개념을 표현
- 할당 연산자 (=) 앞뒤에 공백
- 함수 이름과 괄호는 공백 없이
- 함수 호출시 인자들은 쉼표 다음에 공백주기
- 연산자 우선순위를 표현하기 위해 나중에 계산되는 연산자 앞뒤로 공백
- 들여쓰기
- 소스 파일은 outline과 계층이 비슷
- 파일 전체 정보 -> 개별 클래스 정보 -> 각 메시드 정보 ..
- 범위로 이루어진 계층을 표현하기 위해 들여씀
- 짧은 if, while, 함수 같은 경우에도 한 줄에 쓰기 말고 들여쓰기를 해서 범위를 제대로 표현하는 걸 선호
- 소스 파일은 outline과 계층이 비슷
- 비어있는 while문이나 for문의 경우 다음 행에 세미콜론을 넣어서 표현
- 팀은 한 가지 규칙에 합의해야 한다.
- 괄호는 어디에 쓸건지, 들여쓰기는 몇자리 할 건지, 클래스와 변수 메서드 이름은 어떻게 지을지 등등..
- 헤이딜러 안드로이드 코딩 컨벤션
- https://github.com/PRNDcompany/android-style-guide/blob/main/Kotlin.md
- 명명법부터 개행을 언제는 하고 안 할 건지 등등을 미리 문서로 정해놓으면 여러 사람이 짰어도 형식이 맞기 때문에 일관성 있고 가독성 있는 코드가 된다.
- 사실 이미 다 지키고 있었을 것이다.
- IDE에 기본적으로 설정되어 있는 formatting이 위 내용을 대부분 따르고 있을 것이기 때문이다.