우아한 코스의 Java Style

본격적으로 프리코스 코드 개발에 앞서 , 무작정 코드를 작성하는 것이 아닌
모두가 보편적으로 생각하고 작성하는 코드 스타일에 대해 공부를 하기로 결정했다.
전세계 어디에서든 구글은 인정을 하는 기업이고 , 여기에서 권장해주는 방법을 다른 개발자들도 마다할 이유가 없기 때문이니까
전체 내용에 대한 정리는 따로 노션에 저장을 해두었고 , 해당 글은 내가 중요하다고 생각한 부분만 더 자세하게 작성하고 , 우테코에서 변동한 컨벤션에 대해만 설명하겠다.
밑에 간단한 사담을 추가하고 , 중요하다 생각한 부분은 ⭐️을 붙인다.

2. 소스 파일 기본 사항

파일

• 소스 파일에 포함된 최상위 클래스의 이름 + .java 확장자로 구성
• 인코딩은 UTF-8로 인코딩
  - 유니코드 지원 , 효율적 저장 공간 , 표준 등의 장점으로 인코딩

특수 문자

• Tab 을 들여쓰기에 사용하지 않는다.
• 특수 이스케이프 문자들은 정해져 있다. ( \b \t \n \f \r \" \' \\ )

3. 소스 파일 구조

• 아래와 같은 순서로 큰 틀 작성

1. 라이센스나 저작권 정보 ( 존재 한다면 )
2. 패키지 구축 ( 당연히 하나만 존재 해야함 )
3. import 구문
4. 정확히 하나의 최상위 클래스 ( 중첩 클래스 권장 X )

Import

• 와일드 카드 ( * ) 를 통해 import 하지 않는다.
  - 가독성 , 충돌회피 , 코드 최적화 , 코드 유지보수 등의 이유
• static import 역시 , 권장하지 않는다. ( 위와 비슷한 이유 )

Class

• 클래스 안 멤버 와 함수 순서는 학습 용이성에 매우 중요하다!
  ( 일반적으로 , 대충 생각안하고 작성하는데 , 이는 매우 중요함 - 고려 잘 해나가자 )

괄호 {}

• if 문이나 , else 구문 등 몸체가 없거나 한 줄이여도 괄호를 사용하자 -> 가독성

4. 포매팅

변수

• 매 변수 초기화는 한줄에 하나만 하자. ( int a; b; - 불가능 )

애노테이션

• doc 블럭 이후 클래스 , 함수 , 생성자에 적용
• 각 애노테이션마다 한줄씩 할당하자 ( 들여쓰기 레벨 증가 X )

@Override
@Nullable
public String getNameItPresent(){ ... }

• 예외 : 파라미터 없는 단일 애노테이션은 한줄 쓰기 가능

@Override public int hashCode() { ... }

• 필드 적용 애노테이션들은 한 줄 쓰기 가능

@Partial @Mock DataLoader loader;

5. 식별자 ⭐️⭐️

공통 규칙

• ASCII 문자와 숫자 사용 - \w+ 정규식에 일치되야 함
  => \w 는 워드 문자 , + 는 앞 패턴 하나 이상 일치 : 하나 이상 워드 문자열 패턴

name_ ❌ , mName ❌ , s_name ❌ , kName ❌

Package 이름

• 패키지 이름은 모두 소문자이며 , 연속 된 단어는 단순히 함께 연결 ( 밑줄 X )

com.example.deepSpace ❌ , com.example.deep_space ❌

Class 이름

• 명사 형태
• UpperCamelCase 사용
• 테스크 클래스 이름은 클래스 이름 뒤 Test 를 붙인다.
  => SpecificAsyncedCharacter

Method 이름

• 동사 형태
• lowerCamelCase 사용
  => validateSomeoneIsBuyed
• JUnit 테스트 메소드 이름은 밑줄로 이름논리적상태 구분 가능
  => testLoginFailure_invalidCredentials - 로그인 실패에 대해 테스팅 부적절한 자격

Constant 이름

• 상수 이름은 CONSTANT_CASE
• 모두 대문자 , 밑줄 _ 로 단어 구분
• 내용이 절대적 불변 , 메소드에 감지 가능한 부작용 없는 정적의 최종 필드
  ( 그냥 선언 하고 초기화 한 이후 , 절대 바뀔일 없기에 프로그램도 인지하고 있음 )

Field 이름

• lowerCamelCase 사용
• 공용 메소드에서 한 문자 파라미터 이름 피해야 함 ( 알기 힘듬 )

제네릭 타입 변수 이름

• 각 유형 변수는 두 가지 스타일 중 하나로만 이름 지정

1. 단일 대문자 or 단일 숫자 따라옴
2. 클래스에 사용되는 형식 이름 뒤에 대문자 T ( RequestT , FooBarT )

특별한 단어

EX ) "IPv6" , "iOS" 같은 비정상적 구조가 포함된 경우

1. 구를 일반 ASCII 변환 후 어퍼스트로피 ( ' ) 제거 - Müller's algorithm -> Muellers algorithm : 유니코드 제거 , ( ' ) 제거
2. 단어를 나누고 공백과 나머지 구두점 으로 분리 - AdWords -> ad words
3. 모든 것을 lowercase 후 , 첫 대문자 표시 ad words -> Ad Words
4. 모든 단어 단일 식별자 결합 ( 결국 원래 단어 대소 문자 완전히 무시 가능 ) AdWords

XML HTTP request -> XmlHttpRequest
support IPv6 on iOS -> supportsIpv6OnIos

6. 프로그래밍 실습

@Override

• 메소드 재정의 할 떄 항상 사용하자! ( 컴파일러가 해당 메소드가 실제 부모 & 인터페이스 메소드 재정의 하는지 확인 가능 )
  -> 부모 메소드가 @deprecated 일 경우에는 생략 가능

Caught exceptions

• 예외 처리 코드에서 예외 무시하지 않고 , 적절한 처리 해주는 것을 권장

try {
    int i = Integer.parseInt(response);
    return handleNumericResponse(i);
} catch (NumberFormatException ok) {
    // 예외: 입력이 숫자가 아닌 경우
    // 그냥 계속 진행
}
return handleTextResponse(response);

• catch 문에서 아무것도 안하더라도 , 주석으로 설명하는 것을 권장

Static member

• 정적 클래스 멤버에 대해 참조 해야할 시 , 해당 클래스 이름으로 사용

Finalizers

• finalize 는 객체 소멸자 메소드를 나타내는 특별한 메소드
  ( 가비지 컬렉터 의해 수집 되기 전 호출 되어 추가적인 작업 기대 가능해서 사용할 수 있음 )
  -> 그러나 사용하지 않는걸 권장 ( 아래 이유 )

1. 호출 시점 불확실성 : 언제 수집될 지 정확히 예측 불가능
2. 성능 저하 : 호출될 떄마다 추가적 작업 수행되므로 성능 영향 미침!
3. 대안 존재 : 더 좋은 방법들 있음

7. JavaDoc ⭐️⭐️⭐️

사실 , JavaDoc 부분이 제일 중요하다고 생각한다. 변수 명과 함수 명 및 로직을 아무리 잘 작성해도 부족한 설명이 있을수도 있기 때문에 ,

Formatting

/**
* 여러 줄 JavaDoc 텍스트
* 일반적 래핑
*/
public int method(){}

• 위와 같은 일반적 형태
• 문단 끼리는 빈줄로 구분

블록 태그

• 하단 네가지는 설명과 함께 표시해야함.

    /**  
     * @param - 메소드의 매개 변수에 대한 설명 제공
     * @return - 메소드가 반환하는 값에 대한 설명 제공
     * @throws or @exception - 메소드가 던질 수 있는 예외에 대한 설명 제공 
     * @deprecated - 메소드 , 클래스가 더 이상 사용되지 않거나 권장 되지 않을 때 표시
     */

VS Woowa

이제부터 , 우테코에서 자바와 다른 부분을 설명한다.

[4.2 블럭 들여쓰기: +4 스페이스]

새 블록 또는 블록과 유사한 구조(block-like construct)가 열릴 때마다 들여쓰기가 네 칸씩 증가합니다. 블록이 끝나면 들여쓰기는 이전 들여쓰기 단계로 돌아갑니다. 들여쓰기 단계는 블록 전체의 코드와 주석 모두에 적용됩니다.

=> 기존 Google Style 은 +2 스페이스 , Tab 은 허용되지 않으므로 띄워쓰기 2칸임을 유의해서 코드 작성해야 할 거 같다.

[4.4 열 제한: 120]

Java 코드 열 제한은 120자입니다. "문자"는 유니코드 코드 포인트를 의미합니다.

=> 기존 100자 이나 ,여기서는 120자 제한. 크게 차이가 없을듯

[4.5.2 들여쓰기 지속은 최소 +8 스페이스]

줄 바꿈 시 그 다음 줄은 원래 줄에서 +8 이상 들여씁니다.

=> 블럭 들여쓰기가 +4 스페이스 임에 따라 , 자연스럽게 최소 +8이상 들여씀

[4.6.1 수직 빈 줄]

빈 줄은 가독성을 향상시키기 위해서라면 어디든(예를 들면 논리적으로 코드를 구분하기 위해 문장 사이) 사용 될 수 있습니다. 클래스의 첫 번째 멤버나 초기화(initializer) 또는 마지막 멤버 또는 초기화( initializer) 뒤의 빈 줄은 권장되지도 비권장하지도 않습니다.

클래스의 첫 번째 멤버나 초기화(initializer) 앞에 있는 빈줄을 강제하지 않습니다.

=> 사실상 , 빈 줄을 자유롭게 쓰라는 의미인거 같다.
Java Style Guide 는 수직 빈줄에도 제한하고 비 권장 하는 부분이 있기 때문이다.

사담

코드 컨벤션에 대한 스타일을 대략 살펴보았고 , 주의점 이랑 중요한 부분에 대해 살펴보았다.
이제 , 과제에 대한 코드를 작성하고 해당 코드에 대한 회고록은 제출 후에 작성하겠다.

Writed By Obisidan