“변수는 사용하는 위치에 최대한 가까이 선언하라”는 지침은 코드의 가독성, 유지보수성, 그리고 오류 방지를 개선하기 위한 중요한 프로그래밍 원칙입니다. 이 원칙은 변수를 필요로 하는 코드의 영역과 변수 선언을 가까이 배치함으로써, 코드의 명확성과 효율성을 높이는 데 중점을 둡니다.
가독성 향상: 변수가 사용되는 위치에 가까이 선언되어 있으면, 변수가 어디에서 어떻게 사용되는지 즉시 파악할 수 있어 코드의 가독성이 크게 향상됩니다. 이는 코드의 이해를 돕고, 코드 리뷰나 협업 시에도 도움이 됩니다.
유효 범위 최소화: 변수를 사용하는 위치에 가까이 선언함으로써 해당 변수의 유효 범위(Scope)를 최소화할 수 있습니다. 유효 범위가 좁아지면 변수의 값이 예기치 않게 변경되거나 다른 코드에서 잘못 사용될 가능성이 줄어듭니다.
메모리 관리: 변수를 필요한 곳에서만 선언하고 사용하는 것은 특히 메모리 관리에 유리합니다. 필요 없는 메모리 할당을 피할 수 있고, 변수의 생명주기를 최소화하여 시스템 리소스를 절약할 수 있습니다.
코드 유지보수성 증가: 코드 수정 시, 변수를 사용하는 코드와 그 변수가 선언된 위치가 가깝다면, 변수를 찾고 수정하기가 훨씬 쉬워집니다. 이로 인해 유지보수성이 증가하고, 실수할 가능성이 줄어듭니다.
* 잘못된 패턴
DATA: lv_max TYPE i,
lv_min TYPE i.
* 중간에 로직이 있다고 가정한다.
lv_min = 10.
lv_max = lv_main * 2.
WRITE: / lv_max.
이 경우, lv_max과 lv_min가 코드의 시작 부분에 선언되어 있지만, 실제로는 이 변수를 사용하는 곳과 상당히 떨어져 있습니다.
* 변수 선언을 사용하는 곳과 가깝게 이동 시킨다.
START-OF-SELECTION.
DATA(lv_min) = 10.
DATA(lv_max) = lv_min * 2.
WRITE: / lv_max.
“분기점에서 인라인을 선언하지 마라”는 프로그래밍에서 코드의 가독성, 유지보수성, 그리고 예측 가능성을 높이기 위한 중요한 원칙 중 하나입니다. 이 지침은 조건문이나 반복문 등의 분기점에서 변수를 인라인으로 선언하는 것을 피하라는 의미입니다.
인라인 선언이란?
인라인 선언이란 변수의 선언과 초기화를 한 줄에서 동시에 수행하는 것을 말합니다. ABAP 7.40 이후 버전에서는 DATA() 구문을 사용하여 변수를 인라인으로 선언할 수 있습니다.
DATA(lv_min) = 10.
이 구문은 lv_min 변수를 선언하고 동시에 10으로 초기화합니다.
* 잘못된 패턴
IF flag = 'X'.
DATA(lv_result) = get_node_key( ).
WRITE: / lv_result.
ELSE.
DATA(lv_result) = get_node_key( ).
WRITE: / lv_result.
ENDIF.
위의 코드에서는 lv_result 변수가 IF와 ELSE의 두 분기점에서 각각 인라인으로 선언되었습니다. 이 방식은 코드의 가독성과 유지보수성을 저하시킬 수 있습니다.
분기점에서 인라인 선언을 피하고, 변수는 분기점 바깥에서 미리 선언해 두는 것이 좋습니다. 이렇게 하면 코드의 명확성이 높아지고, 유지보수 및 수정이 더 쉬워집니다.
* 분기점 밖 인라인 선언
DATA(lv_result) TYPE i.
IF flag = 'X'.
lv_result = get_node_key( ).
ELSE.
lv_result = get_node_key( ).
ENDIF.
WRITE: / lv_result.
변수를 분기문 안에서 인라인으로 선언하는 대신, 분기점 바깥에서 미리 선언하고 초기화하는 것이 더 좋다는 원칙입니다. 이 원칙을 따르면 코드의 가독성, 유지보수성, 그리고 예측 가능성을 높일 수 있습니다. ABAP에서는 이를 통해 더욱 깨끗하고 명확한 코드를 작성할 수 있습니다.
“선행 선언을 서로 묶지 마라”는 코딩 스타일 가이드라인 중 하나로, 변수 선언 시 여러 변수를 한 줄에 묶어 선언하지 말고, 각각의 변수를 별도의 줄에 선언하라는 원칙입니다. 이 원칙은 코드의 가독성, 유지보수성, 그리고 코드 리뷰의 용이성을 높이기 위해 제안됩니다.
이 방식은 여러 변수를 한 줄에 선언하는 방법입니다. 하지만 이 방식은 몇 가지 단점이 있습니다.
문제점
1.가독성 저하: 여러 변수를 한 줄에 선언하면 가독성이 떨어집니다. 특히 각 변수의 타입과 이름을 빠르게 파악하기 어려워집니다.
2.유지보수 어려움: 나중에 변수를 추가하거나 수정해야 할 때, 한 줄에 여러 변수가 있으면 수정하기 번거롭고, 실수로 다른 변수의 선언에 영향을 줄 수 있습니다.
3.코드 리뷰의 어려움: 코드 리뷰 시 한 줄에 많은 변수가 있으면 리뷰어가 각 변수를 개별적으로 검토하기 어렵습니다. 이를 통해 오류가 쉽게 발견되지 않을 수 있습니다.
체이닝(Chaining)이란
체이닝이란 동일한 작업을 수행하는 여러 변수를 하나의 구문으로 연결하여 선언, 할당 또는 조작하는 것을 말합니다. 이는 코드의 간결성을 높이고 반복적인 코드를 줄이는 데 도움이 됩니다. 체이닝은 특히 변수 선언, 데이터 할당, 데이터 작업에서 자주 사용됩니다.
* 체이닝 제거 변수 선언
DATA lv_name TYPE string.
DATA lv_age TYPE i.
DATA lv_number TYPE p DECIMALS 2.
“FIELD-SYMBOL보다 REF TO를 사용하라”는 지침은 ABAP 프로그래밍에서 메모리 참조와 관련된 특정 상황에서 FIELD-SYMBOLS보다 REF TO를 사용하는 것이 더 나은 경우를 설명하는 것입니다. 이 원칙은 주로 코드의 안정성, 명확성, 그리고 특정 상황에서의 성능을 개선하기 위한 것입니다.
FIELD-SYMBOLS와 REF TO의 차이점
FIELD-SYMBOLS: FIELD-SYMBOLS는 동적으로 메모리 영역을 가리키는 데 사용됩니다. 이 메모리 영역은 변수, 테이블 행, 구조 등 다양한 데이터 오브젝트일 수 있습니다. FIELD-SYMBOLS를 사용하면 실제 데이터 오브젝트를 직접 참조하게 됩니다.
FIELD-SYMBOLS <fs> TYPE any.
ASSIGN max_data TO <fs>.
위의 코드에서는 max_data가FIELD-SYMBOL인 <fs>로 직접 참조됩니다.
REF TO: REF TO는 객체나 데이터 오브젝트의 참조(포인터)를 저장하는 데 사용됩니다. 참조 변수는 실제 데이터를 직접 참조하지 않고, 데이터 오브젝트에 대한 참조를 가집니다. 이를 통해 참조된 객체나 데이터를 간접적으로 접근할 수 있습니다.
DATA: ref_value TYPE REF TO value_type.
GET REFERENCE OF some_value INTO ref_value.
이 코드에서는 some_value의 참조를 ref_value에 저장합니다. 이후 ref_value을 통해 some_value에 접근할 수 있습니다.
FIELD-SYMBOLS보다 REF TO를 사용해야 하는 경우
객체 지향 프로그래밍: 객체 지향 코드에서는 REF TO를 사용하여 객체 참조를 관리하는 것이 일반적입니다. 이는 클래스와 객체 간의 관계를 명확히 하고, 객체를 보다 안전하게 참조할 수 있게 합니다.
참조의 명확성:REF TO를 사용하면 참조 변수의 타입이 명확해집니다.FIELD-SYMBOLS는 매우 유연하지만, 가리키는 데이터의 타입이 명확하지 않을 수 있습니다.REF TO를 사용하면 참조하는 데이터의 타입이 명확하게 정의됩니다.
안전성:FIELD-SYMBOLS를 잘못 사용하면 예기치 않은 메모리 참조 오류가 발생할 수 있습니다. 반면REF TO는 메모리 관리를 보다 안전하게 할 수 있도록 돕습니다. 예를 들어,REF TO는 객체가 유효하지 않게 되면 참조를INITIAL로 설정할 수 있으므로, 유효하지 않은 참조로 인한 오류를 방지할 수 있습니다.
재사용성 및 유지보수성: 참조를 사용하는 코드가 더 쉽게 재사용 가능하고 유지보수하기 쉽습니다. 특히 큰 프로젝트에서 여러 모듈 간에 데이터를 공유하거나 객체 간의 관계를 명확히 할 때 유용합니다
