두 번째 경고 메시지는 그다지 유용하지 않다. 이 경고의 원인이 대상 타입의 요소에 적절히 이름을 명명하지 않아서 발생한 것이기 때문이다. 그럼에도 불구하고 경고의 원인을 찾을 수는 있다.

이러한 경고는 과연 유용할까? 결론부터 말하면 ‘그렇다.’ 이처럼 변수의 선언과 값의 생성을 한 문장에서 수행하는 경우에는 크게 도움이 되지 않을지 몰라도, 선언과 값의 생성이 분리된 경우에는 상당한 도움이 된다. 예를 들어 예제 11-1의 MinMax 메서드가 리팩터링하기 어렵고 상당히 긴 코드라고 가정해 보자. (min, max)를 반환해야 할까, (max, min)을 반환해야 할까? 이 경우에는 메서드의 이름에 견줘 그 순서를 유추할 수 있다. 하지만 모든 경우가 그렇지는 않을 것이며, 모호한 경우도 상당히 많을 것이다. return 문을 작성할 때 다음과 같이 요소에 이름을 명명하면 검증의 역할을 수행할 수 있다.

return (min: min, max: max);

하지만 순서를 바꿔 다음과 같이 코드를 작성하면 경고 메시지를 출력할 것이다.

return (max: max, min: min);  ----- warning CS8123 두 번 발생

이는 명시적으로 요소의 이름을 명명한 경우에만 적용된다. C# 7.1에서라면 (max, min)이라는 튜플 리터럴이 주어졌을 때 각 요소의 이름을 추론할 것이다. 하지만 이 경우에는 튜플을 (int min, int max) 타입으로 변환해도 경고를 출력하지 않는다.

나는 코드를 작성할 때 다른 사람이 재확인할 필요가 없도록 구조화하는 방식을 선호한다. 하지만 메서드를 더 짧게 리팩터링하기 전에 우선적으로 이와 같은 방식을 적용해 볼 수 있다는 사실을 알아 두면 좋겠다.