개발시 변수명 작성 가이드, 좋은 네이밍의 기준

1. 일관된 네이밍 컨벤션 적용

프로그래밍 언어 및 프레임워크의 컨벤션을 따르는 것이 중요함.

• Camel Case (camelCase) - Java, JavaScript, Kotlin
  • 예: userName, orderTotal
• Pascal Case (PascalCase) - C#, .NET, TypeScript 클래스명
  • 예: UserService, OrderManager
• Snake Case (snake_case) - Python, SQL
  • 예: user_name, order_total
• Kebab Case (kebab-case) - URL, CSS 클래스명
  • 예: main-container, nav-bar

💡 가이드:

• 팀 내에서 하나의 컨벤션을 정하고 일관성 있게 유지할 것.
• 언어별 권장 스타일을 따를 것.

 

2. 의미 있고 직관적인 변수명 사용

변수명만 보고 어떤 역할을 하는지 명확히 알 수 있도록 작성해야 함.

• ❌ a, b, c 같은 추상적인 변수명 사용 금지
• ⭕ userName, orderTotal, customerList 등 의미를 명확히 표현

❌ 나쁜 예	⭕ 좋은 예
dt	orderDate
tmp	tempUserSession
x, y	latitude, longitude

 

3. 약어 및 축약어 사용 지양

• ❌ usrNm, ordDt, custInfo
• ⭕ userName, orderDate, customerInfo

하지만 널리 사용되는 약어는 예외로 인정됨.

• URL, ID, API → userID, fetchAPI

 

4. Boolean 변수는 긍정형으로 작성

Boolean 값을 나타내는 변수는 긍정형 + 동사로 작성하는 것이 일반적임.

• isActive, hasPermission, canEdit, shouldUpdate

잘못된 예

• ❌ notLoggedIn (부정형 네이밍)
• ⭕ isLoggedIn (긍정형 네이밍)

 

5. 상수 변수는 SNAKE_CASE(대문자 + 언더스코어)로 작성

상수 값은 대문자로 작성하고, 단어 간 구분은 _(언더스코어)로 구분.

• MAX_RETRY_COUNT, DEFAULT_TIMEOUT, PI

💡 가이드:

• 환경 변수도 같은 원칙 적용: DATABASE_URL, JWT_SECRET_KEY

 

6. 컬렉션(배열, 리스트, 맵) 변수명은 복수형 사용

배열이나 리스트 같은 컬렉션 변수는 복수형을 사용해야 함.

• users, orders, productList, orderItems

잘못된 예

• ❌ user (단수형이므로 혼동 가능)
• ⭕ users (배열임이 명확)

 

7. 함수와 변수 구분을 위한 명명 규칙

변수는 명사(Noun), 함수는 동사(Verb) 형태로 작성하는 것이 일반적임.

• 변수 예시: userProfile, productList
• 함수 예시: getUserProfile(), fetchOrders(), calculateTotalPrice()

잘못된 예

• ❌ user() → 함수처럼 보이지만 변수임
• ⭕ getUser() → 함수임이 명확

 

8. 도메인(비즈니스 로직) 용어를 반영한 변수명 작성

비즈니스 로직에 맞는 의미 있는 변수명을 사용해야 함.

예: 쇼핑몰 시스템

• ❌ items, price, list
• ⭕ cartItems, totalPrice, customerOrders

 

9. 변수명은 명확성을 위해 길게 작성해도 무방함

길지만 명확한 이름이 짧고 애매한 이름보다 좋음.

• productPrice (O) vs. pp (X)
• customerOrderList (O) vs. col (X)

💡 가이드:

• 너무 길어질 경우, 의미를 해치지 않는 범위에서 줄이기
  • calculateDiscountedProductPrice() → getDiscountedPrice()

 

10. 네이밍 충돌 방지를 위한 접두어/접미어 활용

• tempUser, cachedData, backupFile
• isDeleted, hasAccess, shouldUpdate

💡 가이드:

• 네이밍 충돌이 발생할 가능성이 있는 경우, 도메인 관련 접두어 추가
  • userSessionData, orderHistoryList

 

11. 특정 범위(스코프)에서만 유효한 변수에는 접두어를 추가할 수도 있음

• localUserData: 로컬에서만 사용
• tempPassword: 임시 비밀번호
• cachedOrders: 캐시 데이터

이렇게 하면 변수의 성격을 쉽게 파악할 수 있음.

 

12. 객체 지향적인 변수명 사용

객체를 다룰 때, 변수명도 객체의 속성을 반영해야 함.

class User {
    String name;
    int age;
}

❌ String n;, int a;
⭕ String name;, int age;

💡 가이드:

• 객체의 속성을 명확하게 드러내는 변수명을 사용할 것

 

13. SQL 및 데이터베이스 변수명 규칙

SQL에서는 snake_case를 주로 사용하며, 테이블과 컬럼 명칭은 명확해야 함.

• user_id, order_date, product_price
• ❌ usrId, prdPrc (가독성 저하)

 

14. API 요청/응답 네이밍 규칙

API에서 JSON 필드는 일반적으로 camelCase 또는 snake_case를 따름.

• REST API: userName, orderDate (camelCase)
• GraphQL: userProfile, orderHistory (camelCase)
• SQL: user_name, order_date (snake_case)

💡 가이드:

• REST API에서는 camelCase
• 데이터베이스에서는 snake_case14. API 요청/응답 네이밍 규칙
  • REST API: userName, orderDate (camelCase)
  • GraphQL: userProfile, orderHistory (camelCase)
  • SQL: user_name, order_date (snake_case)
  💡 가이드:
  • REST API에서는 camelCase
  • 데이터베이스에서는 snake_case

 

간략히 정리하면 아래와 같다. 
✅ 일관성 유지 (언어별 네이밍 컨벤션 준수)
✅ 의미 있는 변수명 (축약어 지양, 명확한 의미 전달)
✅ 논리적인 구조 (Boolean, 컬렉션, 함수명과의 구분)
✅ 도메인 용어 반영 (비즈니스 로직과 일치)