[Java] Google Java Style Guide

Hood·2025년 10월 14일

Java

목록 보기
2/5
post-thumbnail

들어가기 전

Java 에 회기하며 해당 언어의 소스 코드에 대한 Google 표준을 참조 합니다. 바로 가보시죠!
(오역이 있을 수 있으니 주의하세요!)


1. 용어 참고 사항

Google Java Style Guide 문서에서는 해당 용어를 다음과 같이 정의합니다.

  1. 클래스는 일반, 레코드, 열거형, 인터페이스 또는 주석 유형을 의미하는데 사용됩니다.
  2. (클래스의) 멤버 용어는 중첩된 클래스, 필드, 메서드 또는 생성자를 모두 의미하는 데 사용됩니다. 즉 초기화를 제외한 모든 최상위 콘텐츠를 의미합니다.
  3. 주석 이라는 용어는 항상 구현 주석을 지칭합니다.
    (문서 주석 이라는 표현은 javadoc를 사용합니다.)

2. 소스 파일 기본 사항

2.1 파일 이름

클래스가 포함된 소스 파일의 경우, 파일 이름은 최상위 클래스의 대소문자로 구분된 이름과 .java 확장자로 구성됩니다.

2.2 파일 인코딩: UTF-8

2.3 특수문자

  • 공백문자: 줄 종료 문자를 제외하면 0x20(Space)는 소스 파일 어디서나 공백 문자입니다.
  1. 다른 모든 공백 문자는 char 문자열 리터럴과 텍스트 블록에서 이스케이프됩니다.
  2. 탭 문자는 들여쓰기에 사용되지 않습니다.
  • 특수 이스케이프 시퀀스 : 가 있는 경우 해당 시퀀스가 8진수 또는 유니코드 이스케이프 \\대신 사용됩니다.
  • 비 ASCII 문자 : 나머지 비 ASCII 문자에는 실제 유니코드 문자 또는 이에 사응하는 유니코드 이스케이프 문자가 사용됩니다.
    코드를 읽고 이해하기 쉽게 만드는 방법에 따라 달라지겠지만 문자열 리터럴과 주석 외부에서 유니코드를 이스케이프하는 것은 권장하지 않습니다.

3. 소스 파일 구조

일반적인 소스 파일은 다음 섹션으로 구성됩니다.
1. 라이센스 또는 저작권 정보
2. Package 구문
3. Import 구문
4. 정확히 하나의 최상위 Class

각 섹션을 구분하기 위해 정확히 한 줄에만 표현합니다.

3.1 라이센스 또는 저작권 정보

파일에 속하면 여기에 속합니다.

3.2 Package 구문

패키지 문은 줄 바꿈되지 않습니다.
열 제한(100)은 패키지 문에 적용되지 않습니다.

3.3 Import 구문

3.3 순서 및 간격

import는 다음과 같이 순서가 정해집니다.
1. 모든 static imports. 는 단일 그룹
2. 단일 그룹의 모든 non-static imports.

static imports와 non-static imports가 모두 있는 경우 하나의 빈 줄이 두 블록을 구분합니다.
❗️import 문 사이에는 다른 빈 줄이 없습니다❗️

각 블록 내에서 가져온 이름은 ASCII 정렬 순서로 표시됩니다.
('.'이 ';'보다 먼저 정렬되기에 import시 주의해야 합니다.)

3.4 클래스 선언

3.4.1 정확히 하나의 최상위 클래스 선언

소스 파일마다 각자의 최상위 클래스가 존재합니다.

3.4.2 클래스 내용 순서

class의 멤버 및 이니셜라이저에 대한 순서는 큰 영향을 미칠 수 있습니다.
하지만 단 하나의 정답은 없고 class마다 순서를 정하는 방식이 다를 수 있습니다.

여기서 중요한 점은 각 클래스가 몇 가지 논리적 순서를 사용한다는 것입니다.
이 순서는 관리자가 요청하면 설명할 수 있어야 한다.
예를 들어 새로운 메서드를 그냥 습관적으로 클래스 끝에 추가하지 않아야 합니다.
그렇게 하면 "추가된 날짜순" 정렬이 되는데 이는 논리적 정렬이 아닙니다.

3.4.2.1 Overloads (절대 위치 분할 금지🚫)

class에 여러 생성자 또는 동일한 이름을 가진 여러 메서드가 있는 경우
이들은 사이에 다른 코드 없이(개인 멤버도 포함 X) 순차적으로 나타나야 합니다.


4. Formatting

block-like construct (블록 같은 구조)는 클래스, 메서드 또는 생성자의 본문을 나타냅니다.
배열 이니셜라이저는 블록형 구조체처럼 취급될 수 있습니다.

4.1 괄호

4.1.1 선택 사항인 경우에서도 중괄호가 사용됩니다.

if, else, for, do, while문 또는 body가 비어 있거나
단 하나의 문이 포함 된 경우에도 괄호가 쓰입니다.

비어 있지 않은 블록 : K & R 스타일

괄호는 비어 있지 않은 블록 및 블록 유사 구조에 대해 Kernighan 및 Richie 스타일을 따릅니다.

  • 여는 중괄호 앞({)에 줄 바꿈이 없음.
  • 여는 중괄호 뒤({)의 줄 바꿈
  • 닫는 중괄호 앞(})에 줄 바꿈
  • 닫는 중괄호 뒤(})의 줄 바꿈
  • 중괄호 뒤에 else 또는 쉼표(,)가 오면 줄 바꿈이 없음.
Example
return () -> { //여는 중괄호 뒤 줄바꿈
  while (condition()) {
    method();
  } // 닫는 중괄호 뒤 줄 바꿈
};

return new MyClass() {
  @Override public void method() {
    if (condition()) {
      try {
        something(); //닫는 중괄호 앞 줄 바꿈
      } catch (ProblemException e) {
        recover();
      }
    } else if (otherCondition()) {
      somethingElse();
    } else { //중괄호 뒤 else 또는 , 에서는 줄바꿈 X
      lastThing();
    }
  }
};

4.1.3 빈 블록 : 간결할 수 있음

빈 볼록 또는 블록과 유사한 구조는 K & R 스타일일 수 있습니다.
또는 다중 블록 명령문(if/else 또는 try/catch/finally)의 일부가 아닐 경우
({ }) 사이에 문자나 줄 바꿈없이 열린 직후 닫을 수 있습니다.

Example
// 허용
void doNothing() {}

// 허용
void doNothingElse() {
}

4.2 블록 들여쓰기 : +2 공백 (-> +4까지)

새 블록 또는 블록과 유사한 구조가 열릴 때마다 들여쓰기가 두 칸씩 증가합니다.
블록이 끝나면 들여쓰기는 이전 수준으로 돌아갑니다.
들여쓰기 수준은 블록 전체의 코드와 주석 모두에 적용됩니다.

4.3 한 줄에 하나의 문

각 문 뒤에는 줄 바꿈이 있습니다.

4.4 열 제한 : 100 (-> 120자 까지)

Java 코드의 열 제한은 100 자입니다.
character는 모든 유니코드 코드 포인트를 의미합니다.
아래의 경우를 제한하고 모든 줄은 4.5 설명대로 줄 바꿈해야합니다.
각 유니코드 코드포인트는 표시 너비가 더 크거나 작아도 한 문자로 계산됩니다.
예를 들어 fullwidth charcters(일본어, 한자, 한글, 숫자)를 사용하는 경우
위치보다 먼저 줄바꿈을 적용할 수 있습니다.

예외:
  1. 열 제한을 따를 수 없는 줄 (ex: Javadoc의 긴 URL이나 긴 JSNI 메서드 참조)
  2. package 선언 및 imoort (섹션 3.2 package 및 3.3 import 참조)
  3. 텍스트 블록의 내용
  4. 셸에 복사하여 붙여넣을 수 있는 주석의 명령줄
  5. 매우 긴 식별자는 드물게 필요한 경우 열 제한이 초과될 수 있습니다.

4.5 줄 바꿈

코드를 하나의 줄에서 여러 줄로 나눌 때 이 작업을 줄 바꿈이라고 합니다.
모든 상황에서 줄 바꿈하는 방법을 정확히 보여주는 공식은 없지만
동일한 코드를 줄 바꿈하는 여러 유효한 방법이 많습니다.
[참고] : 줄 바꿈의 일반적인 이유는 열 제한을 초과하지 않도록 하는 것이지만 실제로 열 제한에 맞는 코드도 작성자의 재량에 따라 줄 바꿈이 될 수 있습니다.
[Tip] : 메서드 또는 지역 변수를 추출하면 줄 바꿈없이 문제를 해결할 수 있습니다.

4.5.1 어디서 줄바꿈을 해야하는가?

줄 바굼의 주요 지침은 더 높은 문법 수준에서 중단하는 것 입니다.
1. 비할당 연산자에서 줄이 바뀔 경우 줄바꿈은 기호 앞에 옵니다.

  • 점 구분 기호 .
  • 메서드 참조의 두 콜론 ::
  • Type 바운드의 앰퍼샌드 <T extends Foo & Bar>
  • catch 블록의 파이프 catch (FooException | BarException e)
  1. 할당 연산자에서 줄이 끊어지면 일반적으로 기호 뒤에 끊어 지지만 어느 쪽이든 허용됩니다.
  • 이는 확장 for(foreach) 문에서 "assignment-operator-like" 콜론에도 적용됩니다.
  1. 메서드 또는 생성자 이름은 그 뒤에 오는 여는 괄호가 있을 때 (()까지 쓰고 줄바꿈)
  2. 쉼표 , 는 그 앞에 있는 토큰에 연결되어 있을 때
  3. lambda의 본문이 중괄호가 없는 단일 식으로 구성된 경우 화살표 바로 뒤에 줄 바꿈이 있을 수 있습니다. 이를 제외하고는 lambda의 화살표 옆에서 줄이 끊어지지 ㅇ낳습니다.
lambda Example
MyLambda<String, Long, Object> lambda = //단일식
    (String label, Long value, Object obj) -> { //화살표 뒤 줄바꿈
        ...
    };

Predicate<String> predicate = str ->
    longExpressionInvolving(str);

4.5.2 연속 줄을 최소 +4 공백 들여 쓰기 (-> +8)

줄 바꿈 시 첫 번째 줄 (각 연속 줄)뒤의 각 줄은 원래 줄에서 적어도 +4만큼 들여쓰기가 됩니다.
연속 줄이 여러 개인 경우 원하는 대로 들여쓰기를 +4 이상으로 변경할 수 있습니다.
일반적으로 두 개의 연속 줄은 구문 상 병렬 요소로 시작하는 경우에만 동일한 들여 쓰기 수준을 사용합니다.

4.6 공백

4.6.1 수직 공백

하나의 빈 줄은 다음과 같은 경우에 나타납니다.
1. 연속적인 멤버 또는 클래스의 초기화 : 필드, 생성자, 메소드, 중첩 클래스, 정적 초기화 그리고 인스턴스 초기화
[예외]: 두 개의 연속된 필드 사이에 다른 코드가 없는 경우 빈 줄은 선택사항, 열거형 상수 사이에 빈 줄

  1. 이 문서의 다른 섹션에서 요구하는 대로 (ex. 섹션 3 소스 파일 구조, 3.3 import 문)
    예를 들어 코드를 논리적 하위 섹션으로 구성하는 명령문 사이와 같이 가독성을 향상시키는 모든 곳에 빈 줄 하나를 삽입할 수 있습니다.
    첫 번째 멤버나 이니셜라이저 앞이나 클래스의 마지막 멤버나 이니셜라이저 뒤의 빈 줄은 권장되지 않습니다.

여러 개의 연속된 빈 줄은 허용되지만 권장되는 것도 아닙니다.

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

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

4.6.2 수평 공백

언어나 다른 스타일 규칙에서 요구하는 경우를 제외하고 리터널, 주석, Javadoc 내부를 제외하고 단일 ASCII 공백은 다음 위치에서만 나타납니다.
1. 해당 줄 뒤에 오는 열린 괄호 ()와 키워드 if, for 분리합니다. ex: catch (
2. 해당 줄 앞에 오는 닫는 중괄호 () else 와 같은 키워드를 분리합니다. ex: catch }

  1. 두 가지 예외를 제외하고 모든 열린 중괄호( { ) 앞에는
    @SomeAnnotation({a, b}) //공백을 사용하지 않음.
    String[][] x = {{"foo"}}; //아래 항목 10에 따라 공백은 필요하지 않음.

  2. 이항 또는 삼항 연산자의 양쪽에 적용됩니다. 이는 다음과 같은 "연산자 유사" 기호에도 적용됩니다.
    여러 유형 Type을 구분하는 앰퍼샌드: <T extends Foo & Bar>
    여러 예외를 처리하는 catch 블록의 파이프: catch (FooException | BarException e)
    for("foreach") 명령문 의 콜론(:)
    람다 표현식의 화살표: (String str) -> str.length()
    [예외] 메소드 참조의 두 콜론 ::은 다음과 같이 작성됨 ex. Object::toString
    다음 .과 같이 쓰여진 점 구분 기호 : object.toString()

  3. 캐스트의 , : ; 또는 닫는 괄호 )

  4. // 모든 콘텐츠와 주석을 시작하는 이중 슬래시 사이 여러 개의 공백이 허용됩니다.

  5. 주석을 시작하는 이중 슬래시(//)와 주석 텍스트 사이 여러 개의 공백이 허용됩니다.

  6. 선언의 tpye과 변수 사이 ex. List<String> list

  7. [선택사항] 배열 초기화의 두 중괄호 바로 안쪽에 있는 공백
    ex. new int[] {5, 6}, new int[] { 5, 6 } 둘 다 유효합니다.

  8. type annotation과 []또는 사이

이 규칙은 줄 시작 또는 끝에 추가 공백을 요구하거나 금지하는 것으로 해석되지 않고 내부 공간만을 다룹니다.

4.7 그룹화 괄호 : 권장

선택적 그룹화 괄호는 작성자와 검토자가 없어 코드를 읽기 쉽게 만들지 않았다는 데 동의하는 경우에만 생략됩니다.모든 독자가 자바 연산자 우선 순위 테이블이 있다고 가정하는 것은 옳지 않습니다.
❗️우선순위가 명확해도 괄호로 감싸는 것을 권장합니다

4.8 특정 구조

4.8.1 Enum 클래스

enum 상수 뒤에 오는 각 쉼표 뒤에 줄 바꿈은 선택 사항입니다.
추가 빈 줄 (일반적으로 하나만)도 혀옹됩니다.

Example
private enum Answer {
YES {
    @Override public String toString() {
        return "yes";
    }
},

    NO,
    MAYBE
}

method와 주석이 없는 enum class는 배열 초기화와 같은 포맷으로 적의될 수 있습니다.

private enum Suit { CLUBS, HEARTS, SPADES, DIAMONDS }

enum 클래스는 classes 이므로 클래스 형식 지정에 대한 다른 모든 규칙이 적용됩니다.

4.8.2 변수 선언

4.8.2.1 선언 당 하나의 변수

모든 변수 선언 (필드 또는 로컬)은 하나의 변수만 선언합니다.
int a, b; 는 사용되지 않습니다.
[예외] : for 루프 헤더에 여러 변수 선언이 허용됩니다.

4.8.2.2 필요할 때 선언

지역 변수는 포함 블록이나 블록과 유사한 구조의 시작 부분에서 습관적으로 선언되지 않습니다.
대신 지역 변수는 범위를 최소화하기 위해 처음 사용되는 지점에 가깝게 선언됩니다.
지역 변수 선언에는 일반적으로 이니셜라이저가 있거나 선언 직후에 초기화됩니다.

4.8.3 Array

4.8.3.1 배열 이니셜라이져 : "block-like"

모든 배열 이니셜라이저는 선택적으로 block-like-construct인 것처럼 형식화 될 수 있습니다.
다음의 경우 모두 사용이 가능합니다.

  new int[] {           new int[] {
  0, 1, 2, 3            0,
}                       1,
                        2,
new int[] {             3,
  0, 1,               }
  2, 3
}                     new int[]
                          {0, 1, 2, 3}

4.8.3.2 C 스타일 배열 선언 없음

대괄호는 변수가 아닌 type의 일부를 형성합니다.
⭕️ String[] args
❌ String args[]

4.8.4 Switch 문

스위치 블록의 중괄호 안에는 하나 이상의 구문 그룹이 있습니다.
각 구문 그룹은 하나 이상의 switch 라벨과 하나 이상의 명령문 ( 또는
마지막 명령문 그룹의 경우 0개 이상의 명령문 )으로 구성됩니다.

4.8.4.1 들여쓰기

다른 블록과 마찬가지로 스위치 블록의 내용은 +2로 들여 쓰기 하면 됩니다.
다음 스위치 레이블은 블록이 닫힌 것처럼 이전 들여 쓰기 수준으로 돌아갑니다.

4.8.4.2 Fall-through: 주석

Switch 블록 내에서 각 문 그룹 중 하나 (break, continue, return 또는 발생한 예외 )
가 돌연 종료되거나 다음 구문으로 넘어가게 적을 수 있습니다.
여기에는 특수 주석을 달 수 있으며 스위치 블록의 마지막 명령문 그룹에는 필요하지 않습니다.

Example
  switch (input) {
  case 1:
  case 2:
    prepareOneOrTwo();
    // fall through
  case 3:
    handleOneTwoOrThree();
    break;
  default:
    handleLargeNumber(input);
}

case 1:다음에 주석이 필요하지 않으며 명령문 그룹의 끝에서만 주석이 필요합니다.

4.8.4.3 default 케이스 존재

각 switch 문에는 default 코드가 없는 경우에도 default 문 그룹이 포함됩니다.
[예외] : enum 유형에 대한 switch 문은 해당 유형의 가능한 모든 경우를 포함하는 명시적 케이스를 처리한 경우 명령문 그룹을 생략할 수 있습니다.
이를 통해 IDE 또는 기타 정적 분석 도구는 누락 된 사례가 있는 경우 경고를 발행할 수 있습니다.

4.8.5 Annotations

클래스, 메서드 또는 생성자에 적용되는 Annoations은 documentation block 바로 뒤에
나타나며 각 어노테이션은 자체 줄에 나열됩니다. (즉, 한 줄에 하나의 어노테이션)
줄바꿈을 구성하지 않으므로 들여 쓰기 수준은 증가하지 않습니다.

Example
@Override
@Nullable
public String getNameIfPresent() { ... }

//[예외] : 파라미터가 없는 단일 annotation은 한 줄 맨 처음에 쓸 수 있다.
@Override public int hashCode() { ... }

/*
* [예외] : 필드에 적용되는 Annotations도 documentation block 바로 뒤에
* 나타나지만 이 경우 여러 주석 (매개변수화 가능)이 같은 줄에 나열 될 수 있습니다.
*/
@Partial @Mock DataLoader loader;

파라미터, 지역 변수 또는 타입에 대한 주석 형식화에 대한 특정 규칙은 없습니다.

4.8.6 주석

구현 주석만을 다루며 Javadoc는 섹션 7에서 별도로 다룹니다.

줄 바꿈 앞에는 임의의 공백과 구현 주석이 올 수 있습니다.
이러한 주석은 행을 공백이 아닌 것으로 랜더링 합니다.

4.8.6.1 블록 주석 스타일

블록 주석은 주변 코드와 동일한 수준에서 들여쓰기 됩니다.
/* ... */이나 // ... 스타일이 있을 수 있습니다.
여러 줄 /* ... */의 경우 후속 줄은 이전 줄에 * 정렬 된것으로 시작해야 합니다.

/*
 * This is          // And so           /* Or you can
 * okay.            // is this.          * even do this. */
 */

주석은 별포 또는 기타 문자로 그려진 박수에 포함되지 않습니다.
[Tip] : 여러 줄 주석을 작성할 때 필요한 경우 자동 코드 포맷터가 줄바꿈을 다시 적용하도록 하려면 문단스타일을 사용합니다.
대부분의 포멧터는 // ... 에서 줄바꿈을 다시 적용하지 않습니다.

4.8.6.2 TODO 주석

TODO는 임시적인 코드, 단기적인 해결책
충분히 좋지만 완벽하지 않는 코드에 주석을 사용합니다.

주석은 모두 대문자로 된 TODO 단어 그 뒤 콜론 ,
그리고 해당 맥락을 담고 있는 리소스 링크 시작됩니다.
버그는 추적되고 후속 주석이 있기 때문에 버그 참조가 더 바람직합니다.
이 맥락 뒤에는 하이픈(-)으로 시작하는 설명 문자열을 추가합니다.
ex. // TODO: crbug.com/12345678 - 2047q4 호환성 창이 만료된 후 이 항목을 제거하세요.

개인이나 팀을 컨텍스트로 언급하는 TODO를 추가하지 마세요.
ex. // TODO: @yourusername - 문제를 제출하고 반복을 위해 '*'를 사용하세요.

4.8.7 수정자

클래스 및 멤버 수정자가 있는 경우 Java 언어 사양에서 권장하는 순서대로 표시합니다.

public protected private abstract default static final sealed non-sealed
transient volatile synchronized native strictfp

4.8.8 숫자 리터널

long 값 정수 리터널은 대문자 L 점미사를 사용하며 소문자는 사용하지 않습니다.
이유는 혼동을 피하기 위해서입니다.
ex. 3000000000l 대신 3000000000L

4.8.9 텍스트 블록

""" 텍스트 블록의 시작은 항상 새 줄에 있습니다.
해당 줄은 다른 구문과 동일한 들여쓰기 규칙을 따르거나 들여쓰기가 전혀 없을 수 있습니다.
즉 왼쪽 여백에서 시작합니다.
닫는 줄은 """ 여는 줄과 같은 들여쓰기로 새 줄에 있으며 같은 줄에 추가 코드가
올 수 있습니다.
텍스트 블록의 각 텍스트 줄은 최소한 여는 줄과 닫는 줄만큼 들여쓰기가 됩니다.

텍스트 블록의 내용이 열 제한을 초과할 수 있습니다.


5. 명명

5.1 모든 식별자에 공통적인 규칙

식별자는 ASCII 문자와 숫자만 사용하며 소수의 경우 _를 사용합니다.
따라서 각 유요한 식별자 이름은 \w+ 정규 표현식과 일치합니다.

Google 스타일에는 특수 접두사나 접미사를 사용하지 않습니다.
ex. name_, mName, s_name, k_name

5.2 식별자 유형별 규칙

5.2.1 패키지 및 모듈 이름

패키지 및 모듈 이름은 소문자와 숫자만 사용합니다. (_ 사용 X)
연속된 단어는 단순히 연결하여 사용합니다.
ex. ⭕️ com.example.deepspace
❌ com.example.deepSpace 또는 com.example.deep_space.

5.2.2 클래스 이름

클래스 이름은 UpperCamelCase로 작성됩니다.
클래스 이름은 일반적으로 명사 또는 명사구입니다.
ex. Character 또는 ImmutableList
인터페이스 이름도 명사 또는 명사구 일 수 있지만 (ex. List)
때로는 형용사 또는 형용사구일 수 있습니다. (ex. Readable)

5.2.3 메서드 이름

메서드 이름은 lowerCamelCast로 작성됩니다.
메서드 이름은 일반적으로 동사 또는 동사구입니다.
ex. sendMessage 또는 stop
Junit 테스트메서드 이름에는 이름의 논리적 구성 요소를 구분하기 위해 밑줄이 사용될 수 있으며
각 구성 요소는 lowerCamelCase로 작성됩니다.
ex. transferMoney_deductsFromSource
테스트 메서드 이름을 지정하는 데는 단 하나의 올바른 방법은 없습니다.

5.2.4 상수 이름

상수 이름은 UPPER_SNAKE_CASE 모두 대문자로 작성되며
각 단어는 밑줄 하나로 구분됩니다.
🤔 상수 란?
불변하고 메서드에 감지 가능한 부작용이 없는 정적 최종 필드입니다.
예를 들어 기본형, 문자열, 불변 값 클래스, null로 설정된 모든 것
인스턴스의 상태가 변경될 수 있는 경우는 상수가 아닙니다.
단순히 객체를 변경하지 않으려는 의도만으로 충분하지 않습니다.

// Constants 상수들
static final int NUMBER = 5;
static final ImmutableList<String> NAMES = ImmutableList.of("Ed", "Ann");
static final Map<String, Integer> AGES = ImmutableMap.of("Ed", 35, "Ann", 32);
static final Joiner COMMA_JOINER = Joiner.on(','); // because Joiner is immutable
static final SomeMutableType[] EMPTY_ARRAY = {};

// Not constants 상수가 아닌 것들 (일반적으로 명사나 명사구이다.)
static String nonFinal = "non-final";
final String nonStatic = "non-static";
static final Set<String> mutableCollection = new HashSet<String>();
static final ImmutableSet<SomeMutableType> mutableElements = ImmutableSet.of(mutable);
static final ImmutableMap<String, SomeMutableType> mutableValues =
    ImmutableMap.of("Ed", mutableInstance, "Ann", mutableInstance2);
static final Logger logger = Logger.getLogger(MyClass.getName());
static final String[] nonEmptyArray = {"these", "can", "change"};

5.2.5 상수가 아닌 필드 이름

상수가 아닌 필드 이름은 lowrCamelCase로 작성됩니다.
이러한 이름은 일반적으로 명사 또는 명사구입니다.
ex. computedValues 또는 index

5.2.6 매개변수 이름

매개변수 이름은 lowerCamelCase로 작성됩니다.
공개 메서드에서는 한 문자로 된 매개변수 이름을 피해야 합니다.

5.2.7 지역 변수 이름

지역변수 이름은 lowerCamelCase로 작성됩니다.
❗️최종적이고 불변적일지라도 지역 변수는 상수로 간주되지 않으며
상수 스타일로 지정해서는 안됩니다.

5.2.8 유형 변수 이름

각 유형 변수는 두 가지 스타일 중 하나로 명명됩니다.
1. 단일 대문자 혹은 선택적으로 숫자 하나가 따라올 수 있습니다. (ex. E, T, X, T2)
2. 클래스에 사용되는 형식의 이름 뒤에 대문자가 붙습니다. (ex. RequestT, FooBarT)

5.3 Camel case : 정의된 단어들

영어 구문을 카멜 표기법으로 변환하는 데 있어 합리적인 방법이 올 수 있습니다.
예를 들어 IPv6iOS와 같이 약어나 특이한 구문이 있는 경우 Google 스타일은
예측 가능성을 높이기 위해 결정론적 체계를 지정합니다.

산물 형식 이름을 시작 :
  1. 구를 일반 ASCII로 변환하고 어퍼스토로피(')를 제거하십시오.
    ex. "Müller's algorithm" -> "Muellers algorithm"이 될 수 있습니다.
  2. 이 결과를 단어로 나누고 공백과 나머지 구두점 (일반적으로 하이픈)으로 분리합니다.
  • 권장 : 일반적으로 사용되는 일반적인 camel-case 방식이 이미있는 단어가 있으면 이를 구성 부분으로 분할합니다.
    ex. "AdWords" -> "ad words"가 됨
    "iOS"와 같은 단어는 실제로 camel case 문자 자체 가 아니며
    어떤 규칙도 위반하므로이 권장 사항은 적용되지 않습니다.
  1. 이제 모든 것을 lowercase(약어 포함)하고 다음의 첫 번째 문자만 대문자로 표시합니다.
  • 각 단어를 upper camel case로 표시하거나
  • 첫 번째 단어를 제외한 각 단어는 lower camel case를 산출합니다.
  1. 마지막으로 모든 단어를 단일 식별자로 결합합니다.
    원래 단어의 대소 문자는 거의 완전히 무시됩니다.
Prose formCorrectIncorrect
"XML HTTP request"XmlHttpRequestXMLHTTPRequest
"new customer ID"newCustomerIdnewCustomerID
"inner stopwatinnerStopwatchinnerStopWatch
"supports IPv6 on iOS?"supportsIpv6OnIossupportsIPv6OnIOS
"YouTube importer"YouTubeImporter , YoutubeImporter *
"Turn on 2SV"turnOn2svturnOn2Sv
"Guava 33.4.6"guava33_4_6guava3346

*는 허용되지만 권장되지는 않습니다.
[참고] : 영어에서는 모호한 일부 단어는 하이픈으로 연결됩니다.
ex. nonempty, non-empty는 둘 다 올바르므로 메서드 이름이
checkNonempty, checkNonEmpty 모두 가능합니다.


6가지 프로그래밍 관행

6.1 @Override : 항상 사용

@Override가 허락 될 때마다 주석으로 표기됩니다.
여기에는 슈퍼 클래스 매서드를 재정의하는 클래스 매서드,
인터페이스 매서드 구현하는 클래스 메소드,
슈퍼 인터페이스 메소드를 재정의하는 인터페이스 메서드,
레코드 구성 요소에 대해 명시적으로 선언된 접근자 메서드가 포항됩니다.
[예외] : @Override 부모 메서드가 @Deprecated 인 경우 생략될 수 있습니다.

6.2 Caught exceptions : 무시되지 않음.

잡힌 예외에 대한 응답으로 아무것도 없는 경우는 매우 드뭅니다. (일반적으로 응답은 예외를 로깅하거나 "불가능"하다고 판단하면 AssertionError로 다시 throw를 하는 것입니다.)
catch 블록에서 아무 조치도 취하지 않는 것이 진정으로 적절할 때
정당화되는 이유는 주석에 설명되어야 합니다.

try {
  int i = Integer.parseInt(response);
  return handleNumericResponse(i);
} catch (NumberFormatException ok) {
  // it's not numeric; that's fine, just continue
}
return handleTextResponse(response);

/*
* [예외] : 테스트에서 포착 된 예외는 expected 이름 이거나
* 이것으로 시작하는 경우 주석없이 무시 될 수 있습니다.
* 다음은 테스트 중인 코드가 있음을 보장하기 위한 매우 일반적인 관용구이기 때문에 주석이 필요없습니다.
*/

try {
  emptyStack.pop();
  fail();
} catch (NoSuchElementException expected) {
}

6.3 Static members : 클래스를 사용하여 정규화

정적 클래스 멤버에 대한 참조가 정규화되어야 하는 경우
해당 클래스는 type의 참조 또는 식이 아닌 해당 클래스의 이름으로 정규화됩니다.

Foo aFoo = ...;
Foo.aStaticMethod(); // good
aFoo.aStaticMethod(); // bad
somethingThatYieldsAFoo().aStaticMethod(); // very bad

6.4 Finalizer : 사용되지 않음

Object.finalize를 재정의하는 것은 극히 드뭅니다.
제거될 예정입니다.


7. Javadoc

이것은 나중에 필요하다 판단되면 다시 작성하도록 하겠습니다.


마무리하며

모든 가이드라인을 읽었다고해서 모두 기억할 수 없겠지만
4. 포멧팅, 5. 명명 스타일을 준수하기 위해 노력하겠습니다.
이를 위해 IDE에 IntelliJ 코드 스타일 설정하기을 적용하여 컨벤션을 지켜나가겠습니다.

profile
달을 향해 쏴라, 빗나가도 별이 될 테니 👊

0개의 댓글