[클린코드] 5장. 형식 맞추기

 

 

---

1. 형식/포맷팅 중요한 이유

✔ 가독성에 필수적이기 때문

① 코드를 수월하게 읽어 나갈 수 있다.

② 아마추어처럼 보이지 않는다.

③ 형식을 맞춤으로써 버그 위험을 줄인다.

 

2. 클린코드 포맷팅 - 행 간격

✔ 적절한 길이 유지

행(row, 세로) : 200Lines 이하 또는 500Lines 미만

→ 현업에서의 대부분의 코드들도 200Lines 정도를 유지한다.

→ 코드 길이가 200Lines을 넘어간다면, 클래스가 여러 개의 일을 하고 있을 수 있다.(SRP위배)

 

"코드 길이를 200줄 정도로 제한하는 것은 반드시 지킬 엄격한 규칙은 아니지만, 일반적으로 큰 파일 보다는 작은 파일이 이해하기 쉽다."

 

 

✔ 밀접한 개념은 가까이, 개념은 빈행으로 분리

- 행 묶음은 완결된 생각 하나를 표현하기 때문에 개념은 빈 행으로 분리한다.

- 변수는 사용되는 위치에서 최대한 가까이 선언한다.

 

3. 클린코드 포맷팅 - 열 간격

✔ 적절한 길이 유지

- 열(col, 가로) : 요즘은 모니터도 크기 때문에 120자 정도 권장

- 가로 공백(밀집도), 들여쓰기를 활용하여 가독성 높일 수 있다.

public class Test { 
	private void measureLine(String line) { 
    	lineCount++; 
        
        int lineSize = line.length(); 
        totalChars += lineSize(); 
        
        lineWidthHistogram.addLine(lineSize, lineCount); 
        
        recordWidestLine(lineSize); 
	} 
}

 

 

4. Java Class Declarations 자바 클래스 선언 포맷팅

class 내부 코드 순서로 아래와 같은 규칙이 있었다

static 필드	public -> protected -> package -> private 순
instance 필드	public -> protected -> package -> private 순
생성자	-

그외 public 메서드에서 호출되는 private 메서드(종속함수)는 그 아래에 둔다. ('가독성' 위주로 그룹핑)

 

 

5. Team Coding Convention

✔ 팀의 코딩 스타일에 관한 약속 

개발 언어의 컨벤션이 우선이지만, 애매한 부분은 팀 컨벤션을 따른다.

→ 🚨확실히 정해 두지 않으면 언쟁💢, 시간 낭비🕛 발생 가능

→ 없다면 함께 만들어 가는 것도 좋아요 👍

 

예시

Mysql Convention : 컬럼명은 snake_case(Underscore , _ ) 로 네이밍함
Team Convention :  enum 타입 사용하는 varchar 타입의 경우 컬럼명은 _type 으로 끝나도록 네이밍한다. 

---

그외. 참고하기 좋은 사이트

Naver가 한글로 되어 있고, 거의 국내 대부분 개발자가 지키는 기본 룰이지 아닐까 싶음

명칭	주소
Naver HackDay Java Convention	https://naver.github.io/hackday-conventions-java
Google Java Style Guide	https://google.github.io/styleguide/javaguide.html
Oracle java language	https://docs.oracle.com/javase/specs/jls/se7/html/index.html

 

그외.  Naver HackDay Java Convetion 관련

해당 문서를 일부 참고하여 Team Convention 정하는 시간을 가졌다.

 

✔ 5.2 닫는 중괄호와 같은 줄에 else, catch, finally, while 선언

// 나쁜 예💩
if (line.startWith(WARNING_PREFIX)) { 
     return LogPattern.WARN; 
}. 
else if (line.startWith(DANGER_PREFIX)) { 
     return LogPattern.DANGER; 
}. 
else { 
     return LogPattern.NORMAL; 
} 

 

해당 규칙에 대해서는 좋은 예시 처럼 닫는 중괄호 뒤에 줄바꿈 하지 않기로 했음 🤝

// 좋은 예👍
if (line.startWith(WARNING_PREFIX)) { 
     return LogPattern.WARN; 
} else if (line.startWith(DANGER_PREFIX)) { 
     return LogPattern.DANGER; 
} else { 
     return LogPattern.NORMAL; 
} 

 

✔ 5.4 조건/반복문에 중괄호 필수 사용

해당 규칙에 대해서는 '나쁜 예의 if문 처럼 한줄로 표현하는 방식' 또한 허용하는 걸로 규칙 정함 🤝

//나쁜 예 💩
if (exp == null) return false; 
for (char ch : exp.toCharArray()) if (ch == 0) return false;

//좋은 예👍
if (exp == null) {
   return false; 
}

for (char ch : exp.toCharArray()) {
    if (ch == 0) {
       return false;
    }
}

 

✔ 8.3. 중괄호의 시작 전, 종료 후에 공백 삽입

//좋은 예👍
public void printWarnMessage(String line) { 
      if (line.startsWith(WARN_PREFIX)) { 
    ... 
      } else { 
    ...
      } 
} 

 

✔ 8.4. 제어문 키워드와 여는 소괄호 사이에 공백 삽입

if, for, while, catch, synchronized, switch 와 같은 제어문 키워드 사이에 공백

//좋은 예👍
if (maxLine > LIMITED) { 
   return false; 
} 

 

 

✔ 8.5. 식별자와 여는 소괄호 사이에 공백 미삽입

// 나쁜 예💩
public StringProcessor () {} // 생성자 

@Cached ("local") 
public String removeEndingDot (String original) { 
    assertNotNull (original); 
    ... 
} 

 

좋은 예 형식을 지키는 것으로 규칙 정함 🤝

// 좋은 예👍
public StringProcessor () {} // 생성자 

@Cached ("local") 
public String removeEndingDot(String original) {  // 함수명과 소괄호가 붙어 있음
    assertNotNull (original); 
    ... 
} 

---

느낀점

“ 오랜 시간이 지나 코드가 바뀌어도, 맨 처음 잡아 놓은 구현 스타일/형식은 남아 유지보수 용이성과 확장성에 계속 영향을 미친다. “ - 📚Clean Code

 

매번 작업시 코드 스타일이 달라 무엇이 맞는 고민했던 기억이 난다. 코드 형식을 맞추고 시작했다면 가독성도 높이는데 좋지 않았을까 싶다.