1. 소개
프로그래밍에서 스타일은 유행이 아니라 생존입니다. Java는 대규모 팀이 사용하는 언어이고, 각자 “익숙한 대로” 코드를 쓰기 시작하면 프로젝트는 금세 서로 연결되지 않은 조각들의 집합으로 변해, 작성자 본인(그조차도 항상은 아님)만 겨우 이해할 수 있게 됩니다.
코드 스타일은 모두가 동일하게 읽을 수 있도록 만드는 규칙의 집합입니다. 도로 표지판과 같습니다. 이를 무시하면 이동은 빠르게 혼란으로 변합니다.
왜 중요할까요?
- 가독성: 코드는 쓰는 것보다 읽는 일이 더 많습니다. 나쁜 스타일은 의사의 악필처럼 아무도 알아보기 어렵습니다.
- 유지보수성: 규칙에 맞춘 코드는 변경이 쉽고, 우연히 무언가를 망가뜨릴 가능성이 줄어듭니다.
- 협업: 팀에서는 불필요한 질문 없이 서로의 코드를 이해할 수 있어야 합니다.
- 도구: 자동 포매터와 정적 분석기는 스타일이 통일될수록 더 잘 작동합니다.
2. 주요 코드 스타일 실수(및 피하는 방법)
들여쓰기와 중괄호를 지키지 않음
문제:
들여기기 없이 괄호도 제멋대로인 코드는 눈과 뇌를 괴롭힙니다.
if(x>0){
System.out.println("x는 양수입니다");
}else{
System.out.println("x는 양수가 아닙니다");
}
올바른 예:
if (x > 0) {
System.out.println("x는 양수입니다");
} else {
System.out.println("x는 양수가 아닙니다");
}
코멘트:
각 중첩 수준마다 공백 4칸을 사용하세요(이것이 Java 표준입니다). 팀에서 합의하지 않았다면 탭 사용은 지양하세요.
부적절한 변수, 메서드, 클래스 이름
문제:
int a = 5;
String s = "Vasya";
void f() { /* ... */ }
올바른 예:
int age = 5;
String userName = "Vasya";
void printReport() { /* ... */ }
코멘트:
이름은 의미가 분명하고 대상의 역할을 드러내야 합니다.
- 클래스 — 대문자로 시작하는 CamelCase: UserAccount.
- 메서드와 변수 — 소문자로 시작하는 camelCase: calculateSalary, userList.
너무 긴 메서드와 클래스
문제:
100줄짜리 메서드, 1000줄짜리 클래스 — 유지보수의 진짜 nightmare mode입니다.
권장:
각 메서드는 한 가지 일만 하고 짧아야 합니다(가능하면 화면 한 페이지에 들어갈 정도). 클래스도 “전쟁과 평화”급 분량이 되지 않도록 하세요.
예시:
나쁨:
public void processOrder() {
// 200줄의 코드
}
좋음:
public void processOrder() {
validateOrder();
calculateTotal();
saveToDatabase();
sendEmailConfirmation();
}
‘매직 넘버’와 하드코딩된 문자열 사용
문제:
if (status == 42) {
// ...
}
올바른 예:
public static final int STATUS_APPROVED = 42;
if (status == STATUS_APPROVED) {
// ...
}
코멘트:
‘매직’ 숫자나 문자열 대신 상수(static final)를 사용하세요. 최신 Java에는 enum도 있으니 값의 집합이 제한적일 때 사용하세요.
주석: 없거나, 지나치게 많거나
문제 1:
주석이 전혀 없어 복잡한 코드의 의도가 보이지 않습니다.
문제 2:
자명한 동작에까지 주석을 답니다.
// x를 1 증가시킵니다
x = x + 1;
// x가 10과 같은지 확인합니다
if (x == 10) {
// ...
}
이런 주석은 오히려 방해만 됩니다! 주석은 복잡하거나 비직관적인 부분에만 작성하세요. 좋은 코드는 주석 없이도 이해 가능해야 하며, 주석은 “무엇”이 아니라 “왜”를 설명해야 합니다.
// VIP 고객 할인 적용을 고려합니다
double total = calculateTotalWithDiscount();
3. Java 컨벤션: 프로는 이렇게 씁니다
Java에는 공식 및 사실상의 코드 스타일 표준이 있습니다. Oracle Java Code Conventions와 Google Java Style Guide가 가장 널리 사용됩니다.
들여쓰기와 중괄호
여는 중괄호는 선언과 같은 줄에 둡니다:
public void print() {
// ...
}
중첩 수준은 공백 네 칸입니다.
네이밍
- 클래스와 인터페이스: 대문자로 시작하는 CamelCase(Person, UserAccount).
- 메서드와 변수: 소문자로 시작하는 camelCase(calculateSalary, userList).
- 상수: UPPER_SNAKE_CASE(MAX_SIZE, DEFAULT_TIMEOUT).
- 패키지: 모두 소문자, 점으로 구분(com.example.project).
공백
연산자 주변과 쉼표 뒤에는 공백을 둡니다:
int sum = a + b;
System.out.println(name, age);
여는 괄호 다음과 닫는 괄호 앞에는 공백을 두지 않습니다:
if (x > 0) { ... }
한 줄 길이
한 줄은 100–120자를 넘기지 않는 것을 권장합니다. (모니터가 아무리 커도, 코드가 가로로 끝없이 길어지면 읽기 어렵습니다.)
클래스 멤버 선언 순서
권장 순서(Oracle):
- 필드(먼저 static, 그 다음 인스턴스)
- 생성자
- 메서드
예시:
public class User {
private static int userCount;
private String name;
public User(String name) {
this.name = name;
userCount++;
}
public String getName() {
return name;
}
}
4. 예시: 나쁜 스타일 리팩터링
야생에서 종종 볼 수 있는 클래스 예시입니다:
class person{String n;int a;void p(){System.out.println(n+" "+a);}}
어딘가의 사무실에서 이 코드를 보고 한 Java‑개발자가 눈물을 흘리고 있습니다.
개선해 봅시다:
public class Person {
private String name;
private int age;
public Person(String name, int age) {
this.name = name;
this.age = age;
}
public void print() {
System.out.println(name + " " + age);
}
}
무엇이 달라졌나요:
- 클래스와 멤버에 올바른 접근 제어자를 적용했습니다.
- 이름이 의미 있고 읽기 쉬워졌습니다.
- 각 클래스 멤버를 새 줄에 배치했습니다.
- 생성자를 사용해 초기화합니다.
- 캡슐화를 위해 필드를 private으로 두었습니다.
5. 유용한 팁
자동 포매터
최신 IDE(IntelliJ IDEA, Eclipse, VS Code)는 표준에 따라 코드를 자동으로 포매팅할 수 있습니다.
단축키:
- IntelliJ IDEA: Ctrl + Alt + L
- Eclipse: Ctrl + Shift + F
정적 분석
Checkstyle, SonarLint, PMD 같은 도구는 프로그램을 실행하기 전부터 스타일 위반과 잠재적 오류를 찾아줍니다.
예를 들어:
- 변수 이름이 x라면 userAge로 바꾸라고 Checkstyle이 경고합니다.
- 메서드가 너무 길거나 클래스가 SOLID 원칙을 위반하면 SonarLint가 알려줍니다.
책임 분리와 ‘클린’ 코드
- 각 클래스는 한 가지 책임만 가져야 합니다(Single Responsibility Principle).
- 새 클래스를 만들고 메서드를 쪼개는 일을 두려워하지 마세요 — 이는 “부풀리기”가 아니라 미래의 독자를 위한 배려입니다.
- 코드 중복을 피하세요: 비슷한 조각이 두 군데 보인다면 별도 메서드로 추출하세요.
상수와 ‘매직 넘버’: 올바른 사용법
대신에:
double price = 100 * 0.18;
더 좋습니다:
public static final double VAT_RATE = 0.18;
double price = 100 * VAT_RATE;
값의 집합이 고정적으로 반복된다면 — enum을 사용하세요:
public enum Status {
NEW, IN_PROGRESS, DONE
}
6. 코드 스타일과 가독성에서 흔한 실수
오류 №1: 코드 컨벤션 무시.
팀에 통일된 스타일이 없으면 코드는 금세 읽기 어렵고 유지보수가 힘들어집니다. 혼자 개발하더라도, 1년 뒤의 당신이 스스로에게 고마워할 겁니다.
오류 №2: 너무 짧거나/너무 긴 이름.
변수 a나 temp — 좋지 않습니다. 변수 theCurrentUserNameThatIsUsedForAuthorizationInTheSystem — 이것도 과합니다. 균형을 찾으세요: userName, age, bookList.
오류 №3: ‘매직 넘버’.
숫자와 문자열을 코드에 직접 박아 넣으면 유지보수가 어려워지고 오류 가능성이 커집니다.
오류 №4: 거대한 메서드와 클래스.
메서드가 클수록 테스트와 이해가 더 어렵습니다. 논리적 단위로 분리하세요.
오류 №5: 엉망인 클래스 구조.
필드가 여기저기 흩어지고 메서드 선언 순서가 제각각이면 필요한 곳을 빠르게 찾기 어렵습니다.
오류 №6: 과도하거나 부족한 주석.
int x = 0; 옆의 “변수 초기화” 같은 주석은 불필요합니다. 복잡한 비즈니스 로직을 설명하는 주석은 매우 중요합니다.
오류 №7: 일관되지 않은 포매팅.
프로젝트의 한쪽은 공백 네 칸, 다른 쪽은 탭, 어떤 곳은 괄호를 새 줄에, 또 다른 곳은 같은 줄에 두면 지저분해 보이고 동료들을 괴롭힙니다.
GO TO FULL VERSION