C#의 params는 같은 형식의 인수를 0개부터 여러 개까지 자연스럽게 받게 해줍니다. 메서드 내부에서는 배열처럼 다루지만, 선언 위치와 오버로드 조합을 잘못 잡으면 호출이 모호해질 수 있어요.
C#의 params는 같은 형식의 인수를 0개부터 여러 개까지 자연스럽게 받게 해줍니다. 메서드 내부에서는 배열처럼 다루지만, 선언 위치와 오버로드 조합을 잘못 잡으면 호출이 모호해질 수 있어요.
호출자는 쉼표로 값을 넘기고 메서드는 배열로 받는다
params int[] numbers로 선언하면 Sum(1, 2, 3)처럼 호출할 수 있습니다. 컴파일러가 인수를 배열 형태로 묶어 전달하며, 이미 int[] 배열이 있다면 그 배열 자체를 넘길 수도 있어요. 인수를 하나도 쓰지 않은 Sum()도 허용되므로 메서드가 빈 배열을 어떻게 처리할지 정해야 합니다.
params는 매개변수 목록의 마지막에 하나만 올 수 있습니다. 앞에는 일반 매개변수를 둘 수 있지만 뒤에는 둘 수 없어요. 서로 다른 형식을 무작정 object[]로 받으면 호출은 편해 보여도 실행 중 형식 검사가 늘어나므로 공통 형식이나 제네릭 설계를 먼저 검토합니다.
배열을 넘기는 호출과 여러 값을 나열하는 호출을 구분한다
Sum(values)는 기존 배열을 전달하는 호출이고 Sum(1,2,3)은 컴파일러가 전달 구조를 만들어 주는 호출입니다. 반복이 매우 잦은 성능 민감 경로에서는 할당과 호출 형태를 측정해야 하지만, 대부분의 일반 코드에서는 API의 읽기 쉬움이 먼저예요.
null을 명시적으로 전달하면 빈 호출과 의미가 달라질 수 있습니다. nullable 경고를 켜고 null을 허용하지 않도록 계약을 정하거나, 메서드 시작에서 ArgumentNullException.ThrowIfNull을 사용하세요. 빈 배열은 정상 입력인지 오류인지도 문서와 테스트에 남겨야 합니다.
오버로드가 많으면 편리함이 모호함으로 바뀐다
같은 이름에 params 버전과 여러 고정 매개변수 버전을 함께 두면 어떤 오버로드가 선택되는지 읽기 어려울 수 있습니다. 특히 선택적 매개변수, 제네릭, 암시적 변환이 섞이면 호출 결과를 추측하기 힘들어요. 자주 쓰는 한두 형태만 고정 오버로드로 제공하고 나머지를 params로 받을지 검토합니다.
공개 API라면 호출 예제와 빈 입력, null, 큰 입력에서의 동작을 함께 문서화하세요. 단순히 인수를 많이 받기 위한 기능이 아니라 같은 의미의 값 묶음을 읽기 좋게 전달할 때 쓰는 문법입니다.
static int Sum(params int[] numbers)
{
int total = 0;
foreach (int number in numbers) total += number;
return total;
}
Console.WriteLine(Sum(1, 2, 3));적용 전에 확인할 체크리스트
기존 화면은 작성 당시의 기록으로 보존했습니다. 현재 작업에서는 제품·서비스·언어 버전과 공식 문서의 적용 대상을 먼저 맞추세요. 설정이나 코드를 한 번에 크게 바꾸지 말고, 변경 전 상태를 기록한 뒤 작은 예제로 결과를 확인하는 편이 안전합니다.
문제가 생기면 같은 조작을 반복하기보다 정확한 오류 문구, 사용 버전, 재현 단계, 기대한 결과와 실제 결과를 적어 두세요. 공개된 캡처에는 계정 주소, 비밀 키, 일련번호처럼 악용될 수 있는 정보가 없는지도 확인합니다.
자주 묻는 질문
기존 게시일과 URL은 바뀌나요?
아니요. 기존 글을 같은 URL에서 보완했으므로 과거 기록과 연결은 유지됩니다.
예전 화면과 현재 화면이 다르면 무엇을 따라야 하나요?
이미지는 당시 맥락을 이해하는 참고 자료로 보고, 실제 조작은 현재 버전의 공식 문서와 화면 문구를 기준으로 하세요.
한 번 확인한 뒤 계속 같은 방법을 써도 되나요?
버전과 정책이 바뀔 수 있습니다. 업데이트 뒤에는 핵심 동작과 보안 조건을 다시 확인해야 합니다.
공식 자료
이 글은 기존 게시물의 URL과 이미지 기록을 유지하면서, 현재 독자가 잘못 적용하기 쉬운 부분을 공식 자료에 맞춰 다시 정리했습니다.
0 댓글