2. Tab 문자 대신 공백문자(ASCII horizontal space character (0x20))로만 들여쓰기함
3. 유니코드와 유니코드 이스케이프 문자
String 내의 유니코드 문자는 굳이 이스케이프로 쓰지 않아도 됨. 이스케이프로만 나타낼 수 있다면 주석으로 뭔지 표기
4. 소스파일에서, 표기해야 할 라이센스/저작권 정보가 있다면 패키지 정보보다 위인 최상단에 와야 한다.
5. 빈 줄 연이어 쓰지 말기 ( Exactly one blank lineseparates each section that is present. )
6. 임포트에서 와일드카드 임포트(.*) 불가 : Wildcard imports, static or otherwise,are not used.
7. static imports와 non-static imports가 있다면 문단을 나눠준다.
8. import 정렬 순서는 아스키정렬 순서
9. 클래스에는 static import 불가 - 스태틱 중첩 클래스들에는 노멀 임포트
10. 메서드는 논리적 순서에 따라 정렬 (만든 순으로 아무렇게나 넣지 말고 나름대로 규칙있게 정리해서)
11. 한 클래스 안에 생성자가 여럿이거나 같은이름 함수가 여럿이라면 반드시 연이어 나와야 함. 중간에 다른 게 끼면 안 됨
12. if 문 등에서 {중괄호}를 생략할 수 있더라도 생략하지 않고 써준다.
13. 괄호 등 포괄문은 Kernighan and Ritchie style ("Egyptian brackets") 를 따른다.
자주 보던 그 형식, 중괄호 뒤에서 줄바꿈하고 닫는 중괄호들을 한 줄로 처리 위는 가능, 아래는 불가능. 위와 같이 심플 구조면 줄바꿈 안 해도 되지만 굳이? 외우기 힘든데 걍 줄바꿈하자
14. 구글 자바 스타일 가이드 기준은 들여쓰기 2칸이지만, 우테코는 4칸을 적용함
15. 한 줄에 한 문장, 줄바꿈 필수
16. 1열에 100자까지만 작성 - 예외: 긴 URL, 긴 메서드, package/import문, 카피해온 명령문에 대한 주석 단, 우테코에서는 120자까지 허용한다.
17. 연속 줄바꿈은 허용은 되는데 사용 안 하는 방향으로...
18. 공백 사용
어려우니까 여러 번 보자. chatGPT로 돌린 번역. 원문이랑 거의 비슷하게 매끄럽게 번역해줌!
19. 변수 선언 시 1줄에 1개 선언, 타입이 같다고 함께 선언할 수 없다.
이렇게 2개 한꺼번에 선언 X
20. 지역변수는 범위 최소화를 위해 첫사용 지점에 가깝게 선언되며, 주로 선언 직후 초기화되게 만든다.
21. 배열 선언 시 한 줄이 아니라 블럭형태로, 중괄호 뒤에 줄바꿔서 상자 형태로 선언
전체적으로 뭘 선언할 때 이 형태("Block-like Construct")가 기본인 거 같다.
22. 배열 선언 등 대괄호 사용 시 타입 뒤에 정의 ( 예: String[] args )
23. 스위치문의 형태 참고
case 1 에는 아무런 주석이 붙지 않는다. 다음으로 계속됨을 나타내는 중간 case(여기서는 2)에는 붙고, 마지막 케이스에서는 역시 붙지 않는다.
24. 어노테이션은 한 줄에 하나만 존재 - @Override 나, @Partial@Mock DataLoader loader; 처럼, 줄바꿈이 필요없는 경우를 제외하고) - @Target(ElementType.TYPE_USE) 타입-유즈 애너테이션의 경우 무조건 한 줄에 씀. ex. final@NullableString name;
25. 주석은 완전 여러 줄인 경우만 빼고는 다 // 로만 감싸자.
26. 제어자(Modifier) 순서 암기
public protected private abstract default static final transient volatile synchronized native strictfp
27. Long 값을 가지는 정수리터럴은 l이 아니라 L. 형태가 1이나 다른 거랑 헷갈리니까 대문자로 쓴다.
28. 식별자는 문자와 숫자만 사용, _은 사용 가능하나 지양하자. 접두사 쓰지 말랍신다! ( these names are not Google Style: name_, mName, s_name,kName. )
29. 패키지 이름은 모두 소문자 only, 언더스코어도 카멜도 X
30. 클래스 이름은 대문자로 시작하는 카멜케이스 명사. 인터페이스 이름은 명사 또는 형용사. 테스트 클래스 이름은 테스트중인 클래스명 뒤에 Test 붙인 거.
31. 메서드 이름은 소문자로 시작하는 카멜케이스 동사.
32. 상수 이름은 전체 대문자 + 언더스코어 명사. ex. CONSTANT_CASE
상수가 무엇이냐? 의 정의와 용례. 이것만 봐도 명쾌하다.
33. 상수가 아닌 스태틱 필드명, 파라미터명 (퍼블릭 메서드에서는 혼란을 방지하기 위해 반드시 1캐릭터 이상으로 명명), 지역변수명 (final, 불변인 경우에도 지역변수는 상수 취급 X), 은 소문자로 시작하는 카멜케이스 명사.
34. 타입 변수명은 2가지 스타일이 있다.
숫자가 따라붙는 1캐릭터 대문자거나, 클래스명에 T가 붙거
35. 카멜 케이스는 아래와 같이 사용. iOS가 Ios, 2SV가 2sv가 되는 부분은 참고하는 게 좋을듯 (모든 건 띄어쓰기가 기준이다.)
역시 프로그래밍에 영어는 필수구나
36. @Override는 붙을 수 있는 곳에 모두 붙인다.
오버라이딩의 정의와 일맥상통하는
37. try - catch문에서, exception이 있으면 로그에라도 기록. 만약 catch 부분에서 아무것도 안 쓰려면 이에 대한 설명 주석 필요 아래 expected 처럼 쓰는 경우에만 아무것도 안 하면서 주석 생략 가능하다.
/**
* 여러 줄에 걸쳐 작성된 Javadoc 텍스트입니다.
* 일반적인 방법으로 줄바꿈을 합니다...
*/
public int method(String p1) { ... }
또는 다음과 같은 한 줄짜리 Javadoc도 가능합니다:
/** 매우 짧은 Javadoc입니다. */
기본 형식은 항상 사용 가능합니다. 하지만 Javadoc 블록 전체(주석 기호 포함)가 한 줄에 모두 들어갈 경우 한 줄 형식을 사용할 수 있습니다. 단, @return과 같은 블록 태그가 포함될 때는 한 줄 형식을 사용하지 않습니다.
7.1.2 단락(Paragraphs)
단락 사이에는 한 줄의 공백(정렬된 별표 *만 포함된 줄)이 들어갑니다. 블록 태그 그룹이 있을 경우, 그 앞에도 공백 줄을 둡니다. 첫 번째 단락을 제외한 모든 단락은 첫 단어 앞에 <p> 태그를 붙이며, <p> 뒤에는 공백이 없습니다.
<ul> 또는 <table>과 같은 다른 블록 수준 HTML 태그는 <p>로 시작하지 않습니다.
7.1.3 블록 태그(Block tags)
표준 블록 태그는 @param, @return, @throws, @deprecated 순서로 작성됩니다. 이 네 가지 태그에는 빈(empty) 설명을 두지 않습니다.
블록 태그의 내용이 한 줄에 들어가지 않을 경우, 두 번째 줄부터는 @ 위치에서 4칸 이상 들여쓰기합니다.
7.2 요약(fragment) 작성
모든 Javadoc 블록은 요약(fragment)으로 시작합니다. 이 요약은 클래스 및 메서드 색인과 같은 특정 문맥에서 표시되는 유일한 부분이므로 매우 중요합니다.
요약은 명사구나 동사구 형태로 작성하며, 완전한 문장이 아닙니다. “A {@code Foo} is a...”, “This method returns...”와 같은 문구로 시작하지 않으며, “Save the record.”와 같은 명령문으로 작성하지도 않습니다. 하지만 문장처럼 대문자로 시작하고 문장부호를 포함합니다.
팁: 다음과 같은 Javadoc 형식은 잘못된 것입니다:
/** @return the customer ID */ // 잘못된 예시
이 경우 다음과 같이 수정해야 합니다:
/** Returns the customer ID. */ // 올바른 예시
7.3 Javadoc 작성 기준
7.3.1 예외: 자명한 멤버(self-explanatory members)
getFoo()와 같이 단순하고 자명한 멤버의 경우, Javadoc은 선택 사항입니다. 즉, 설명이 “Returns the foo” 외에는 쓸 내용이 없을 때는 생략할 수 있습니다.
중요: 단순히 "자명하다"는 이유로 독자가 필요로 할 정보를 생략해서는 안 됩니다. 예를 들어, getCanonicalName() 메서드의 경우, "Returns the canonical name."이라고만 작성할 수 있다고 해도 독자가 “canonical name”의 의미를 모를 수 있으므로 문서를 생략해서는 안 됩니다.
7.3.2 예외: 메서드 재정의(Overrides)
상위 타입(supertype)의 메서드를 재정의(override)하는 메서드에는 항상 Javadoc을 작성하지 않아도 됩니다.
7.3.4 필수가 아닌 Javadoc(Non-required Javadoc)
필수가 아닌 클래스 및 멤버에 대해 Javadoc을 필요하거나 원할 때 작성할 수 있습니다.
클래스나 멤버의 전반적인 목적이나 동작을 설명하는 주석을 작성할 경우, 이를 일반 주석이 아닌 Javadoc(/**)으로 작성합니다.
필수가 아닌 Javadoc은 7.1.1, 7.1.2, 7.1.3, 7.2절의 형식 규칙을 반드시 따를 필요는 없지만, 따르는 것이 권장됩니다.
우테코 자바 스타일 가이드 (주요)
1. 들여쓰기는 스페이스 4번 2. 열 제한은 120자. 3. 들여쓰기 지속은 스페이스 8번부터 - 이 부분이 좀 헷갈리긴 하는데 아마 첫 들여쓰기는 8스페이스라는 뜻일까? 4. 줄바꿈은 어디든 사용 가능 - 1번씩만 사용하자. 5. .xml 파일을 제공하여 내 프로젝트에 쉽게 적용할 수 있게 되어 있다. 우테코 자바 스타일 가이드(GitHub) 6. 프리코스 커뮤니티에 [BE] Jazzy님이 올려주신 블로그 글을 참고해서 .xml 파일 적용하는 법을 익혔다. (이 자리를 빌어 또 감사 드립니다.) [우테코 7기] IntelliJ 코드 스타일 설정하기!
생각해 볼 점
1. 들여쓰기 지속에 대해 .xml 파일 적용해서 알아봐야겠다. 2. 탭이 아니라 스페이스로 들여쓰기하는 버릇 들이기 3. 여러 번 다시 읽어야 할 것 같다.
비고
1. 모르는 개념, 아는지 모르는지 불명확한 개념이 몇 개 있어서 TIL에 정리하려고 한다. 2-1. chatGPT가 다른 건 몰라도 번역은 정말 기똥차게 한다. 영어 원문과 비교해서 보는데 파파고나 구글 번역보다 낫단 생각이 들면서, 가까운 미래에 언어 장벽이 깨지는 건 아닐까하는 추측도 자연스레 이어졌다. 2-2. 번역을 직접 해보는 건 어떨까? 내 영어+chatGPT라면 더 매끄럽게 할 수 있을 것 같다. 3. 생각보다 이거 정리하는 데 오래 걸림. 1시간이면 읽을 줄 알았는데, 정리와 번역과 이해까지 2시간 반이 소요되었다. 당연히 후속 계획도 밀림😭 영어 공부 좀 더 해야겠다.
