5. 네이밍(naming)

5.1 모든 식별자에 적용되는 공통 규칙(rules common to all identifiers)

식별자(identifier)는 ASCII 문자와 숫자만 사용하며, 아래에 언급된 소수의 경우에만 밑줄(underscore)를 사용합니다. 따라서, 각 유효한 식별자 이름은 정규식(regular expression) \w+ 와 일치합니다.

(구글 스타일에서는) 특수한 접두사나 접미사를 사용하지 않습니다. 예를 들어, name_, mName, s_name, kName과 같은 이름은 (구글) 스타일이 아닙니다.

5.2 식별자 유형별 규칙(rules by identifier type)

1. 패키지 명 (Package names)

패키지 명은 모두 소문자이며, 연속된 단어는 간단하게 서로 연결됩니다. (밑줄 없음) 예를 들어, com.example.deepSpace나 com.example.deep_space가 아니라 com.example.deepspace로 패키지명을 작성합니다.

2. 클래스 명 (Class names)

클래스 이름은 UpperCamelCase(단어가 시작되는 맨 앞 한글자를 대문자로 작성하는 유형)로 작성합니다. 클래스 이름은 일반적으로 명사나 명사구입니다. 예를 들어, Character 나 ImmutableList와 같습니다. 인터페이스(Interface) 이름은 명사나 명사구(예를 들면, List)일 수도 있지만, 때로 형용사나 형용사구가 될 수도 있습니다. (예 : Readable)

어노테이션 유형의 명명(naming annotation type)에 대해서는 특정 규칙이나 잘 정립된(well-established) 규정(convention)은 없습니다.

테스트 클래스(Test class)는 테스트 중인 클래스 이름으로 시작하여 Test로 끝나는 이름으로 명명합니다. 예 : HashTest 또는 HashIntegrationTest

3. 메서드 명 (Method names)

메서드 이름은 lowerCamelCase(맨 앞 한글자는 소문자로, 다음 단어의 맨 앞 한글자는 대문자로 작성하는 유형)로 작성합니다. 메서드 이름은 일반적으로 동시 또는 동사구로 작성합니다. 예를 들면 다음과 같습니다. 

Ex) sendMessage 또는 stop

밑줄은 lowerCamelCase로 작성된 각 컴포넌트와 이름을 논리적으로 구분하기 위해 JUnit 테스트 메서드에 나타날 수 있습니다. 한가지 일반적인 패턴은 <methodUnderTest>_<state>의 형태입니다. (예: pop_emptyStack). 테스트 메서드의 이름을 지정하는 단 한가지의 완벽한 방법은 없습니다.

4. 상수 명 (Constant names)

상수 명은 CONSTANT_CASE와 같은 유형을 사용합니다. 상수 명은 모두 대문자이며, 각 단어는 하나의 밑줄로 다음 단어와 구분됩니다. 하지만, 정확하게 상수가 무엇일까요?

상수는 내용이 변경되지 않고(immutable), 메서드에 부작용(side effect)이 전혀 없는 static final field 입니다. 여기에는 기본형(primitives), 스트링형(Strings), 불변 유형(immutable type), 불변 유형의 불변 컬렉션(immutable collection)이 포함됩니다. 만약 인스턴스의 관찰 가능한 상태가 변경될 수 있다면, 그것은 상수가 아닙니다. 객체를 변경하지 않으려는 의도만으로는 충분하지 않습니다.

예를 들면 다음과 같습니다.

// Constants

static final int NUMBER = 5;

static final ImmutableList<String> NAMES = ImmutableList.of("Ed", "Ann");

static final ImmutableMap<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 = {};

enum SomeEnum { ENUM_CONSTANT }

// 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. 비상수 필드 명 (Non-constant field names)

상수가 아닌 필드 명(non-constant field name)은 (static이든 아니든) lowerCamelCase로 작성됩니다.

이러한 이름은 일반적으로 명사 또는 명사구로 작성됩니다.

예를 들면 다음과 같습니다.

Ex) computedValues 또는 index

6. 파라미터 명 (Parameter names)

파라미터(매개변수 : parameter) 명은 lowerCamelCase로 작성됩니다.

Public 메서드에서 단일 문자 파라미터 이름은 피해야 합니다.

(다른 사람이 변수 명을 이해할 수 없습니다.)

7. 지역 변수 명 (Local variable names)

지역 변수 명은 lowerCamelCase로 작성합니다. final이나 immutable의 경우에도, 지역 변수는 상수로 간주하지 않으며 상수 스타일로 코드를 작성하면 안 됩니다.

8. 유형 변수 명 (Type variable names)

각 유형 변수 명은 다음 2가지 스타일 중 하나로 작성합니다.

 - 단일 대문자, 선택적으로 뒤에 단일 숫자 추가 (ex. E, T, X, T2)

 - 클래스에 사용되는 형태의 이름 뒤에 대문자 T (ex. RequestT, FooBarT)

5.3 카멜 케이스(camel case : defined)

“IPv6”이나 “iOS”와 같이 두문자어나 특이한 구조가 있는 경우처럼 영어 구문을 Camel Case(영어 대소문자로 변환)로 변환하는 합리적인 방법이 한가지 이상 있습니다. 예측 가능성을 개선하기 위해서 Google Style 표준에서는 다음과 같은 (거의) 결정적인 스키마를 지정합니다.

산문형 이름으로 시작 : 

1. 어구를 ASCII로 변환하고 Apostrophe(‘)를 제거하세요. 예를 들어, “Müller's algorithm”는 “Muellers algorithm”으로 변환됩니다.

2. 이 결과를 공백과 나머지 구두점(punctuation)으로 (일반적으로 hypen: ‘-‘)으로 분할하여 나눕니다.

• 권장(Recommended) : 이미 전통적인 Camel Case를 일반적으로 사용하고 있다면, 구성요소로 분할합니다. (예 : AdWord는 ad word로 분할됨) 하지만, “iOS”와 같은 경우는 Camel Case가 아니기 때문에 어떤 규칙에도 위배됩니다. 따라서 이 권장사항은 적용되지 않습니다.

3. 모든 항목(약어 포함)을 소문자로 만든 다음, 첫번째 문자만 대문자로 합니다.

• … 각 단어를 Upper Camel Case로 사용하거나, (각 단어의 첫글자를 대문자로)
• … 각 단어의 첫번째 글자를 제외하고,  Lower Camel Case로 사용합니다. (첫 단어의 첫글자 소문자, 다른 단어의 첫글자는 대문자로)

4. 끝으로, 모든 단어를 단일 식별자로 결합합니다.

원래 단어의 대소문자는 거의 대부분 무시되는 것에 유의하세요.

예:

YoutubeImporter* : 수용 가능하지만, 권장하지 않습니다.

Note : 일부단어는 영어에서 모호하게 ‘-‘으로 연결됩니다. : 예를 들어, “nonempty”와 “non-empty”는 모두 정확하기 때문에 checkNonempty, checkNonEmpty도 모두 정확한 표현입니다.