ABAP Clean Code : Naming 좋은 이름 짓기 2편

이 글은 『Clean ABAP – A Style Guide for Developers』 서적 (written by Klaus Haeuptle, Florian Hoffmann, Rodrigo Jordão, Michel Martin, Anagha Ravinarayan, Kai Westerholz) 을 참고하여 작성하였습니다. 해당 내용을 좀 더 쉽고 이해할 수 있도록 요약/정리 및 개인적인 의견을 붙여 재구성한  포스팅입니다. 

 

 

🔗ABAP Clean Code : Naming 좋은 이름 짓기 1편

---

4. 클래스는 명사를 메서드에는 동사를 사용하자.

• 클래스(CLASS)는 객체 그 자체를 표현하기 때문에 명사 또는 명사구(Noun phrase)를 사용하여 이름을 짓는다. 클래스 이름은 무엇(what)을 나타내는지 명확해야 한다. 

❌ Bad Case
CLASS manage_customer  →  클래스는 동사로 시작하면 안 됨
CLASS read_sales_orders  →  동사는 메서드에서 쓰는 것이 적절

✅ Good Case
CLASS customer_manager  →  고객 정보를 관리하는 클래스
CLASS log_manager            →  로그를 관리하는 클래스 

 

• 메서드(METHODS)는 객체가 수행할 수 있는 행동이나 기능, 작업(action)을 나타내므로, 항상 동사 또는 동사구(Verb phrase)로 이름 짓는다.

❌ Bad Case
METHODS customer_data   →  동사가 없음
METHODS message_adder  →  명사로 메서드를 정의하면 안 됨

✅ Good Case
METHODS get_customer_info  →  고객 데이터를 가져오는 메서드
METHODS add_message           →  메시지를 추가하는 메서드

 

• 반환값이 Boolean(True or False)인 메서드는 is 또는 has 같은 동사로 시작하면 더욱 읽기 쉽다. 질문 형태로 읽히도록 만드는 것이 가독성 측면에서 효과적이기 때문이다.

❌ Bad Case
METHODS empty  →  의미가 명확하지 않음
METHODS approval_status  →  상태를 뜻하는 명사는 혼란 유발

✅ Good Case
METHODS has_approval  →  주문이 승인되었는지 확인하는 메서드

예시:
IF order->has_approval( ).
" 승인된 주문 처리
ENDIF.

 

💡함수(Function) 또한 메서드(Method)와 동일하게 행동을 나타내므로, 동사 형태로 이름 짓는 게 바람직하다. 

---

5. Noisy Words ( 소음 단어 )는 피하자.

소음 단어는 변수명이나 메서드명 등에 자주 쓰이지만, 실제로는 아무런 의미나 가치를 전달하지 못하는 단어를 말한다.
말 그대로 "없어도 되는 단어", 또는 "코드의 흐름을 방해하는 단어"이다.

Noisy Word	의미 없는 이유
data	변수니까 당연히 데이터임 → 불필요
object	클래스든 구조든 다 객체니까 의미 없음
value	대부분 변수는 값을 가지니까 의미 없음
var, variable	변수명에 또 "변수"라고 쓰는 건 중복

 

❌ Bad Case
DATA alv_grid_object TYPE REF TO cl_gui_alv_grid.
DATA max_count_value TYPE i.

✅ Good Case
DATA alv_grid TYPE REF TO  cl_gui_alv_grid .
DATA max_count TYPE i.

---

6. 일관된 용어를 유지하자.

비슷한 역할을 하는 서브루틴 이지만 read, get, make 등 용어가 제각각이면 헷갈린다.

❌ Bad Case
PERFORM make_billing.
PERFORM read_order.
PERFORM get_documents. 

✅ Good Case
PERFORM read_billing.
PERFORM read_order.
PERFORM read_documents. 

 

👉 동의어라도 하나로 통일하면 가독성이 높아지며, 일관성 있는 소스 코드가 되어 깔끔해진다. 

---

7. 이제 필요하지 않은 헝가리 표기법

헝가리 표기법(Hungarian Notation)은 프로그래밍에서 변수 이름 앞에 그 변수의 '자료형'이나 '의도'를 나타내는 접두어(prefix)를 붙이는 방식을 말한다. 예전에는 코드 편집기가 지금처럼 똑똑하지 않았기 때문에, 변수 이름만 보고 자료형을 구분하는 게 중요했었다. 따라서 lv_, iv_, ev_ 같은 접두어로 변수 역할을 구분했었다.

 

🔊 현대 개발에서의 단점

1. IDE가 자료형을 바로 보여주기 때문에 굳이 붙일 필요가 없음

• ADT(ABAP Development Tools)나 Eclipse 같은 도구를 쓰면 마우스만 올려도 타입이 나온다.

2. 이름이 길어지고 의미 전달이 흐려짐

• lv_total_amount 보다는 그냥 total_amount 가 더 깔끔하고 명확할 수 있다.

3. 코드 리팩토링 시 혼란 유발

• 실무에서 흔히 접할 수 있는 문제로 "G"(글로벌) "L"(로컬) 접두어를 수정하지 않아 잘못 사용되는 등 변수 타입이 바뀌었는데 접두어는 그대로 두면, 오히려 잘못된 정보가 된다.

❌ Bad Case
DATA: lv_total_amount TYPE p DECIMALS 2,
           iv_quantity TYPE i,
           ev_result TYPE p DECIMALS 2.

✅ Good Case
DATA: total_amount TYPE p DECIMALS 2,
           quantity TYPE i,
           result TYPE p DECIMALS 2.

 

 

✍️ 헝가리 표기법을 피하는 것이 정말 좋은 방법일까?

물론, 아직까지도 많은 프로젝트나 시스템에서는 SAP GUI를 중심으로 개발하는 경우가 많고, Eclipse 기반의 ADT(ABAP Development Tools)는 일부 환경에서만 사용되고 있는 것이 현실이다. 그렇기 때문에 헝가리 표기법에 대한 호불호는 여전히 존재하고, 어떤 개발 환경이냐에 따라 그 실용성도 달라질 수 있다.

🔔결론적으로, 개발 팀의 합의와 상황에 따라 유연하게 적용하는 것이 가장 바람직하다.
     📌 ADT를 사용한다면, 헝가리 표기법 없이도 충분히 의미 전달이 가능하고 코드가 더 깔끔.
     📌 SAP GUI 환경이라면, 접두어로 역할을 구분해 주는 것이 실용적일 수도 있음.