Code ‐ Abstraction

Naming Conventions

1. 단수와 복수를 구분하기

• 끝에 -(e)s를 붙여 단수/복수를 드러내는 것만으로도 중요한 정보를 전달한다.

// Bad
List<Order> order = orderRepository.findAll();
Order orders = orderRepository.findById(id);

// Good
List<Order> orders = orderRepository.findAll();
Order order = orderRepository.findById(id);

2. 이름 줄이지 않기

• 줄임말은 가독성을 제물로 효율을 얻는 것 — 대부분 잃는 게 더 크다. 다만 관용적 줄임말(id, url, dto)은 허용.

// Bad
int usrCnt;
LocalDate regDt;
void calcTotAmt() { ... }

// Good
int userCount;
LocalDate registeredDate;
void calculateTotalAmount() { ... }

3. 은어/방언 대신 도메인 용어 쓰기

• 농담에서 파생된 용어, 우리 팀만 아는 용어는 금지. 필요하면 도메인 용어를 먼저 정의한다.

// Bad  ("결제 취소"를 팀 은어로)
void ppuck(Order order) { ... }   // "빠꾸"
boolean isYolo;

// Good
void cancelPayment(Order order) { ... }
boolean isFirstPurchase;

4. 좋은 코드를 보고 습득하기

• 비슷한 상황에서 자주 쓰는 단어·개념을 표준 라이브러리/오픈소스에서 익힌다.

// Bad  (직접 만든 어색한 이름)
List<User> userBox;
boolean checkUserExistOrNot(Long id);

// Good  (표준 컬렉션/JPA 관례를 따름)
List<User> users;
boolean existsById(Long id);

5. 일관성 유지하기(한 개념엔 한 단어)

• 같은 개념을 find/get/retrieve/fetch로 섞어 쓰지 않는다. 다른 개념에 같은 단어도 쓰지 않는다.

// Bad
User getUser(Long id);
Order fetchOrder(Long id);
Product retrieveProduct(Long id);

// Good  (조회는 find 로 통일)
User findUser(Long id);
Order findOrder(Long id);
Product findProduct(Long id);

6. 대칭되는 짝 맞추기

• 반대 동작은 관용적 짝으로: open/close, add/remove, start/stop, create/delete, begin/end.

// Bad
void addItem(Item item);
void deleteItem(Item item);   // add 의 짝은 remove

// Good
void addItem(Item item);
void removeItem(Item item);

7. Boolean은 상태를 묻는 형태로(부정형 금지)

• is / has / can / should 접두어를 쓰고, 부정형 이름은 피한다(이중 부정 방지).

// Bad
boolean deleted;
boolean isNotValid;           // !isNotValid 이중 부정 발생

// Good
boolean isDeleted;
boolean isValid;              // 필요할 때 !isValid
boolean hasPermission;
boolean canCancel;

8. 검색 가능한 이름 (매직 넘버/문자열 제거)

• 코드에 박힌 숫자·문자열은 상수로 이름 붙여 grep 으로 추적·수정 가능하게 한다.

// Bad
if (gameStatus == 1) { ... }
for (int i = 0; i < 7; i++) { ... }

// Good
private static final int GAME_STATUS_WIN = 1;
private static final int WORK_DAYS_PER_WEEK = 7;

if (gameStatus == GAME_STATUS_WIN) { ... }
for (int day = 0; day < WORK_DAYS_PER_WEEK; day++) { ... }

9. 단위와 의도를 이름에 담기

• 숫자·시간은 단위를 붙인다. 단위 혼동(ms vs s)은 실제 장애로 이어진다.

// Bad
int timeout;
long size;
int delay;

// Good
int timeoutMs;
long fileSizeInBytes;
int delaySeconds;

10. 스코프에 비례한 길이

• 좁은 지역변수는 짧게, 넓게 쓰이는 필드·public 요소는 길고 구체적으로. 불필요한 문맥은 뺀다.

// Bad  (Order 클래스 내부인데 접두어 중복)
class Order {
    Long orderId;
    LocalDate orderDate;
}

// Good
class Order {
    Long id;
    LocalDate date;
}

// 좁은 스코프는 짧아도 OK
for (int i = 0; i < size; i++) { ... }

11. 불용어(noise word) 빼기

• Info, Data, Manager, Processor, Helper, the 등 의미 없는 단어를 붙이지 않는다.

// Bad
class ProductInfo { ... }
class ProductData { ... }
UserManager theUser;

// Good
class Product { ... }
User user;

12. 타입 정보를 이름에 인코딩하지 않기(헝가리안 회피)

• 타입을 이름에 넣지 않는다 — 타입이 바뀌면 이름이 거짓말이 된다. 컬렉션은 복수형이면 충분.

// Bad
String strName;
int iCount;
String[] boardArray;
List<User> userList;

// Good
String name;
int count;
String[] board;
List<User> users;

13. 계층/역할 컨벤션 따르기 (백엔드)

• 프레임워크 관례를 존중하고, REST URL 은 명사·복수형으로 짓는다(행위는 HTTP 메서드가 표현).

// Bad
class OrderHandler { ... }
class OrderManager { ... }
// GET /getOrders,  POST /createOrder

// Good
class OrderController { ... }
class OrderService { ... }
class OrderRepository { ... }
class OrderResponse { ... }
// GET  /orders/{id}
// POST /orders

Methods and Abstraction

Method Declaration

Abstraction Levels

Magic Numbers, Magic Strings