Programming/기타

네이밍 컨벤션 최종정리

armyost 2023. 8. 28. 15:13
728x90

각 벤더사 가이드 + NEIS 프로젝트 명명규칙 + "내코드가 이상한가요?"

 

개요
아래 명명규칙은 Oracle/Apple 개발자가이드, 전문서적의 내용을 기반하여 프로젝트 개발현황을 참고하여 합리적으로 보이는 수준에서 정리한 것으로, 실 프로젝트의 명명규칙 설계는 프로젝트 특수성을 반영하여 진행 권장

- Oralce Naming Rule : https://www.oracle.com/java/technologies/javase/codeconventions-introduction.html
- Apple Naming Rule : https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CodingGuidelines/Articles/NamingBasics.html

기본적인 명명규칙

Package 모두 소문자로 표시. 조직의 내부적인 고유한 Naming Convention을 그대로 따르면 된다. com.sun.eng
com.apple.quicktime.v2
edu.cmu.cs.bovik.cheese
Class 파스칼 표기법 class Raster;
class ImageSprite;
Interface 파스칼 표기법 interface RasterDelegate;
interface Storing;
Methods 카멜 표기법 run();
runFast();
getBackground();
Variables 짧으면서도 의미가 있어야 한다. 그렇다고 하나의 스펠링으로 만들어도 안된다. 

다만, 임시변수는 i, j, k, m을 많이 사용하는 편이며, integers를 위한 임시변수는 n을 사용한다. character를 위한 임시변수는 c, d, e 가 있다.

파라미터로 다니는 변수는 소문자와 언더바'_'로 표시한다. 그래야 사용할때 로컬변수와 구분할 수 있다.		 int i;
char c;
float myWidth;
Constrants 모두 대문자, 언더바(_)로 구분 static final int MIN_WIDTH = 4;
static final int MAX_WIDTH = 999;
static final int GET_THE_CPU = 1;

Class 명명규칙

  명명규칙 비고
Controller Domain명 + Controller  
Service OrderRegisterService 도메인명을 그대로 따르는것은 피하고 세분화 할 수 있도록 한다.
예) OrderService (X)

Method 명명규칙
Method는 CRUD 형태에 따라 다음과 같은 접두사/접미사를 붙인다
※ DAO/DTO 또는 Collection을 참조하는 메서드는 직관적으로 SQL용어를 사용하고, 기타 유형의 메서드는 SQL 용어가 아닌 목적에 기반하여 네이밍

Controller Method 규칙 예시 기능
orderList() 목록조회 유형 
orderDetails() 단건 상세조회 유형
orderSave() 등록/수정/삭제가 동시에 일어나는 유형
orderAdd() 등록만 하는 유형
orderModify() 수정만 하는 유형
orderRemove() 삭제만 하는 유형

 

Service Method 규칙 예시 기능
findOrder() 조회 유형
addOrder() 등록 유형
modifyOrder() 변경유형
removeOrder() 삭제유형
saveOrder() 등록/수정/삭제가 동시에 일어나는 유형

 

Dao Method 규칙 예시 기능
selectOrder() 조회 유형
insertOrder() 등록 유형
updateOrder() 변경 유형
deleteOrder() 삭제 유형
selectListOrder() 목록 조회 유형
selectPagingListOrder() 목록 조회 유형(페이징처리)

 

좋은 네이밍이 되기 위한 규칙

 

1. 기술을 중심으로 이름을 짓거나, 일련번호를 매겨 이름을 지으면 코드에서 어떠한 의도도 읽어낼수 없습니다. 읽고 이해하는데 시간이 오래 걸릴 뿐더러 기능을 일일이 매핑시킨 알람표(스프레드시트)는 바쁜업무로 인해 유지보수가 거의 이루어 지지 않습니다.

 

권장하지 않는 예 1) 기술중심 명명

class MemoryStateManager {
    void changeIntValue01 (int changeValue) {
        updateState01();
...
}

 

종류 예
컴퓨터 기술 유래 memory, cache, thread, register 등
프로그래밍 기술 유래 function, method, class, module 등
자료형 이름 유래 int, str, flag 등

[기술 중심 명명 예]

 

권장하지 않는 예 2) 일련번호 명명

class Class001 {
   void method001();
   void method002();
...
}

 

권장하지 않는 예 3) 주석, 추가 자료로 대체하는 명명

int d = 0;             // d : 대미지 크기, p1 : 플레이어의 기본 공격력, d1 : 적의 방어력....
d = p1 + p2;
d = d - ((d1 + d2) / 2);
if (d < 0) {
   d=0;
]

 

권장하는 예

int damageAmount = 0;
damageAmount = playerArmPower + playerWeaponPower;
damageAmount = damageAmount - (( enemyBodyDefence + enemyArmorDefence) / 2);
 
if ( damageAmount < 0 ) {
   damageAmount = 0;
}

 

2. 목적과 의도가 있는 명명

Class에 적합한 크기의 책무와 비 상속관계의 Class간의 강한 결합을 방지하려면, Class와 Method에 적절한 이름을 붙여야 합니다. 이름을 대충 붙이다 보면 책무가 엉켜 강한 결합이 되고 클래스가 거대해져 유지관리가 힘들수 있습니다. 이를 방지하기 위해서는 '목적 중심 이름 설계'에 충실해야 합니다.

목적 중심 이름 설계는 이름에서 목적과 의도를 읽고 이해할 수 있게 설계하는 것입니다.

 

권장하지 않는 예

온라인 쇼핑몰은 상품을 중심으로 이루어 집니다. 출고, 예약, 주문, 발송 등 상품을 다루는 유스케이스가 많습니다. 따라서 이름을 단순하게 상품 클래스라고 붙이면, 여러 유스케이스와 관계를 맺게 됩니다. 그러면 상품 클래스가 여러 클래스와 관련 있는 로직을 갖게 되고 점점 거대하고 복잡해질 것입니다. 강한 결합 구조가 되어 버리는 것입니다.

 

따라서 관심사(〓 유스케이스, 목적, 역할)에 따라서 각각 클래스로 분할해야 합니다.

 

권장하는 예

단순하게 존재를 나타내는 이름은 의미가 여러곳에서 사용되기 쉬우며, 목적이 불분명해지기 쉽습니다.

존재 기반 목적 기반
주소 발송지, 배송지, 업무지 ...
금액 청구금액, 소비세액, 연체 보증료, 캠페인 할인 금액 ...
사용자 계정, 개인프로필, 직무 ...
사용자 이름 계정이름, 닉네임(별칭), 본명, 법인명 ...
상품 입고 상품, 예약 상품, 주문 상품, 발송 상품 ...

[목적 기반으로 생각한 이름의 예]

 

 

3. 복잡한 업무시스템의 경우 약어, 코드표 사용에도 조직의 컨센서스가 있어 관리가 효율적인 경우가 있습니다.

 

약어 명명규칙

약어 2자 명명규칙

- 두 단어 복합어의 경우

           . 각 단어의 첫 철자 2개를 약어로 함

                      General Administration → GA

           . 첫 단어의 첫 자와 마지막 단어의 마지막 자음을 합쳐서 약어로 함

                      General Administration → GN

- 한 단어인 경우

           . 첫 철자와 첫 철자를 제외한 첫 번째 자음으로 조합

                      Corporation → CR

           . 첫 자와 마지막 자음을 합쳐서 약어로 함

                      Corporation → CN

           . 처음 두글자를 약어로 함

                      Corporation → CO

- 두 단어 이상인 경우

           . 첫 단어와 다음 단어의 첫 철자 2개를 약어로 합

                      Naming Convention Inspection → NC

           . 첫 단어와 마지막 단어의 첫 철자 2개를 약어로 함

                      Naming Convention Inspection → NI

 

약어 3자 명명규칙

- 세 단어 복합어의 경우

           . 각 단어의 첫 철자 3개를 악어로 함

                      Naming Convention Inspection → NCI

           . 첫 철자와 첫 철자를 제외한 첫 번째 자음과 마지막 단어의 첫 철자를 약어로 함

                      Naming Convention Inspection → NAI

- 한 단어의 경우

           . 첫 철자와 첫 철자를 제외한 처음 자음과 두 번째 자음을 3개를 악어로 함

                      Corporation → CRP

           . 첫철자와 첫 철자를 제외한 첫 번째 자음과 마지막 자음을 합쳐서 약어로 함

                      Corporation → CRN

           . 각 단어의 첫 절자 3개를 약어로 함

                      Corporation → COR

- 두 단어 복합어의 경우

           . 쳐음 단어의 첫 철자와 첫 철자를 제외한 처음 자음과 마지막 단어의 첫 철자를 약어로함

                      General Administration → GNA

           . 처음 단어의 첫 철자와 마지막 자음과 마시막 단어의 첫 철자를 합쳐서 약어로 함

                      General Administration → GLA

           . 첫 단어의 첫 철자와 마지막 단어의 첫 철자와 첫 철자를 제외한 처음 자음을 조합

                      General Administration → GAD

- 네 단어 이상인 경우

           . 처음 3 단어의 첫 철자 3개를 약어로 함

                      Naming Convention Inspection Service → NCI

           . 처음 2 단어의 각 첫 철자 2개와 마지막 단어의 첫 철자를 합쳐서 약어로 함

                      Naming Convention Inspection Service → NCS

 

'Programming > 기타' 카테고리의 다른 글

코드 품질올리기, 코드 설계 - 2 분기중접 줄이기 (2/3)  (0) 2023.08.28
코드 품질올리기, 코드 설계 - 2 분기중접 줄이기 (1/3)  (0) 2023.08.28
코드 품질올리기, 코드 설계 - 1 이름의 중요성과 모델링  (0) 2023.08.28
어플리케이션 구성요소별 Naming Convention  (1) 2023.06.26
GraphQL Apollo 서버와 MySQL 연동  (0) 2023.04.01

'Programming/기타'의 다른글

  • 현재글네이밍 컨벤션 최종정리

관련글

티스토리툴바