Clean ABAP ④ 문자열, 불리언, 조건문, IF/CASE 정리

3줄 요약

• 고정 문자열과 문자열 조합을 구분하고, 참·거짓은 abap_bool과 관련 상수로 표현해요.

• 조건은 가능하면 긍정형으로 쓰고, 복잡한 조건은 의미 있는 변수나 메서드로 나눠요.

• IF의 중첩을 줄이고, 간단한 비교로 충분한 상황에서는 정규식을 사용하지 않아요.

어떤 상황에서 쓰나요

문자열을 합치거나 참·거짓을 검사하는 코드는 짧아 보여도 자주 반복돼요. 이번 글에서는 문자열·불리언·조건문을 읽기 쉽게 쓰는 기준을 알아봐요. 복잡한 IF를 나누는 방법과 정규식 대신 간단한 비교를 쓸 수 있는 상황도 살펴볼게요.

복잡하게 얽힌 조건은 의미 있는 작은 조건으로 나누어 보면 이해하기 쉽습니다. 아래 그림처럼 조건의 뜻을 먼저 드러내고, 분기의 깊이는 얕게 유지하는 것이 목표입니다.

핵심 내용

문자열

• 고정 문자열은 백틱으로 써요. DATA(some_string) = ABC.는 곧바로 string이 돼요. 작은따옴표는 불필요한 타입 변환을 하고 CHAR 인지 STRING 인지 헷갈리게 해요. |ABC|는 CONSTANTS에 쓸 수 없고 고정값에는 쓸데없는 부담이에요.

• 조립은 문자열 템플릿으로 해요. 어느 부분이 리터럴이고 어느 부분이 변수인지 잘 보여서, &&로 이어 붙이는 것보다 읽기 쉬워요.

DATA(message) = |Received HTTP code { status_code } with message { text }|.

불리언

• 불리언은 신중하게 써요. 처음엔 is_archived가 자연스러워 보여도, 곧 "보관 중" 같은 상태가 생겨 열거형이 필요해지는 경우가 많아요. 종류를 구분하는 용도로는 불리언이 대개 나쁜 선택이에요.

• 타입은 abap_bool, 비교는 abap_true/abap_false로 해요. char1, 'X', space, IS INITIAL 비교는 불리언임이 안 보이거나, abap_bool의 기본값이 abap_false 임을 독자가 떠올려야 해서 피해요. 다이내프로 필드처럼 DDIC 요소가 필요하면 abap_boolean을 써요. 이 규칙은 ABAP 프로그래밍 지침에 근거해요.

• 대입은 xsdbool 이에요. IF ... ELSE 4줄이 한 줄이 되고, boolc/boolx보다 타입 변환이 한 번 덜해요. 이름이 어색하다는 것은 가이드도 인정해요. 대안으로 COND abap_bool( WHEN ... THEN abap_true )도 있지만 더 길어요.

DATA(has_entries) = xsdbool( line IS NOT INITIAL ).

조건

• 긍정형으로 써요. has_entries = abap_true가 has_no_entries = abap_false보다 낫지만, 이를 위해 빈 IF 분기를 만들 정도로 밀어붙이지는 말아요.

• IF variable IS NOT INITIAL., NP, <>처럼 IS NOT 형태를 NOT IS보다 먼저 써요. 논리적으로 같아도 머릿속에서 뒤집는 수고가 들어서예요.

• 불리언 메서드는 IF is_empty( table ).처럼 호출만으로 조건을 만들 수 있어요(서술형 메서드 호출). 이 줄임은 "비어 있지 않음 = 참, 비어 있음 = 거짓"인 반환 타입에만 쓸 수 있다는 점은 기억해요.

• 복잡한 조건은 xsdbool로 의미 있는 이름의 변수(example_provided, one_example_fits)에 나눠 담거나, 아예 메서드(is_provided)로 빼요. ADT의 퀵 픽스로 조건을 변수로 추출할 수 있다고 해요.

IF / CASE

• 빈 IF 분기를 두지 말고 조건을 뒤집어요.

• 대안이 여러 개면 ELSEIF 사슬보다 CASE가 좋아요. 서로 배타적인 대안이라는 점이 드러나고, 새 경우를 추가하기 쉬우며, 중첩 실수도 막아 줘요. 마지막 WHEN OTHERS.에서 예외를 던지면 안전해요.

• 중첩은 얕게 유지해요. 깊은 IF는 테스트 케이스가 기하급수적으로 늘어요. 하위 메서드와 불리언 도우미 변수로 풀거나, IF <this> AND <that>.처럼 합쳐요.

정규식

• 단순한 방법이 있으면 정규식을 쓰지 않아요. matches( val = input regex = '.+' ) 대신 input IS NOT INITIAL, contains( ... regex = 'abc' ) 대신 sub = 'abc' 예요. 정규식은 파싱과 컴파일 때문에 메모리와 시간도 더 써요.

• 이미 있는 기반 검사를 다시 만들지 않아요. 클래스 이름 검증이라면 정규식 대신 SEO_CLIF_CHECK_NAME 함수 모듈이에요.

• 복잡한 정규식은 조각 상수로 조립하면 어떻게 만들어졌는지 보여 줄 수 있어요.

주의할 점

• 이 장의 규칙은 7.40 이상 문법(xsdbool, 문자열 템플릿, 인라인 선언)을 전제로 해요. 더 낮은 릴리스에서는 쓸 수 있는 형태가 달라요. 쓰기 전에 대상 시스템에서 문법 검사를 해 보세요. (7.40 기준은 원문에 적힌 것이 아니라 일반적으로 알려진 정보예요.)

• xsdbool은 가이드의 선택일 뿐 유일한 답이 아니에요. 팀 표준이 COND 라면 그쪽이 나을 수도 있어요.

• 정규식 장은 "쓰지 마라"가 아니라 "더 단순한 방법이 있으면 그걸 먼저"예요. 원문도 복잡한 경우를 위한 조립 요령을 따로 소개해요.

• 이 글은 원문을 읽고 정리한 것이고, 예제를 직접 실행해 보지는 못했어요.

• 원문은 2019년에 처음 공개되어 2025년 3월에 마지막으로 고쳐진 문서예요(제가 읽은 판은 2026년 10월 기준). 이 글은 읽고 정리한 것이고 예제를 직접 실행해 보지는 않았어요.

원문 주소: https://github.com/SAP/styleguides/blob/main/clean-abap/CleanABAP.md#strings