가독성 보조 도구로 명명 된 인수 (매개 변수)

오래 전에 ADA에서 많은 프로그램을 작성했으며 함수를 호출 할 때 인수 이름을 지정하는 것이 일반적이었습니다.-SomeObject.DoSomething (SomeParameterName => someValue);

C #에서 명명 된 인수를 지원하므로 인수의 의미가 명확하지 않은 상황에서이 습관으로 되돌릴 생각입니다.

인수가 의미하는 바가 항상 명백해야한다고 주장 할 수도 있지만 부울 인수가 있고 호출자가 "true"또는 "false"를 전달하는 경우 이름으로 값을 한정하면 호출 사이트를 더 읽기 쉽게 만듭니다.

contentFetcher.DownloadNote (note, manual : true);

true 또는 false (이 경우 수동, 자동)를 사용하는 대신 Enum을 만들 수 있다고 생각합니다.

코드를 쉽게 읽을 수 있도록 때때로 명명 된 인수를 사용하는 것에 대해 어떻게 생각하십니까?

이것은 C ++의 개발에서 제안되었으며 Stroustrup은 "C ++의 디자인과 진화", 153 페이지 및 다음 페이지에서 이에 대해 설명합니다. 제안은 잘 정립되었으며 Ada와의 사전 경험을 바탕으로 작성되었습니다. 채택되지 않았습니다.

가장 큰 이유는 아무도 매개 변수가 많은 기능을 장려하기를 원하지 않았기 때문입니다. 언어의 각 추가 기능에는 비용이 들며, 나쁜 프로그램을보다 쉽게 ​​작성할 수 있도록 기능을 추가 할 필요가 없었습니다.

또한 표준 헤더 이름, 특히 일반적인 헤더 및 코드 파일 규칙에 대한 질문도 제기되었습니다. 일부 조직은 .h 파일에 더 길고 더 설명적인 매개 변수 이름을 가지고 있으며 .cpp 파일에 이름을 더 짧고 쉽게 입력 할 수 있습니다 (원하는대로 파일 접미사 대체). 이것들을 동일하게 요구하면 컴파일에 추가 비용이 들게되며 소스 파일 사이에 이름을 섞으면 미묘한 버그가 발생할 수 있습니다.

함수 호출이 아닌 객체를 사용하여 처리 할 수도 있습니다. 12 개의 매개 변수를 사용하는 GetWindow 호출 대신 12 개의 개인 변수를 사용하여 Window 클래스를 만들고 필요에 따라 setter를 추가하십시오. setter를 연결하면 다음과 같은 내용을 작성할 수 my_window.SetColor(green).SetBorder(true).SetBorderSize(3);있습니다. 실제로 작업을 수행하는 함수를 호출하는 다른 기본값을 가진 다른 함수를 가질 수도 있습니다.

의 문서 효과에 대해 걱정이되는 경우 contentFetcher.DownloadNote(note, manual : true);언제든지와 같은 내용을 작성할 수 contentFetcher.DownloadNote(note, /* manual */ true);있으므로 문서에서 그다지 도움이되지 않습니다.

이것이 "모범 사례"보다는 잘못된 코드를 더 읽기 쉽게 만드는 문제라고 생각합니다.

20 개의 매개 변수를 취하는 방법 (또는 계약자)을 갖는 것은“나쁜 냄새”이며 설계상의 문제로 인한 것일 수 있습니다. 그러나 메소드가 많은 매개 변수를 취할 때 코드 작업을 강요 받으면 명명 된 매개 변수는 코드를 이해하기 어렵게 만듭니다.

메소드에 1 또는 2 개의 매개 변수 만 있고 매개 변수가 무엇인지 메소드 이름에서 분명한 경우 이름 지정된 매개 변수는 아무 것도 추가하지 않습니다. 이것은 이상적인 경우입니다.

당신이 작업하는 모든 코드가“ 깨끗한 코드 ”책으로 작성된다면, 명명 된 매개 변수는 거의 쓸모가 없지만 우리는 현실 세계에 살고 있습니다.

매개 변수 이름을 추가하면 더 읽기 쉽습니다. 그러나 내가 읽은 대부분의 책은 부울 스위치를 나쁜 습관으로 생각합니다. 나는 때때로 이것을한다 :

public Content DownloadNote(Note note)
{
    return downloadNote(note, manual: false);
}

public Content DownloadNoteManually(Note note)
{
    return downloadNote(note, manual: true);
}

API를 구현할 때 더 많은 유연성을 제공합니다. 또한 여러 부울 스위치가있는 경우를 제어 할 수 있지만 모든 스위치가 동시에 활성화 될 수는 없습니다.

유형과 의미가 메소드 이름에서 명확하지 않은 상황에서 명명 된 매개 변수를 크게 믿는 사람입니다. 내 경험은 문서를 읽는 사람은 거의 없다는 것입니다.

즉, 명명 된 매개 변수는 의미있는 인수 목록을 만들고, 도우미 개체를 사용하여 (의미 적으로 관련된 인수를 "연결"), 관련이있는 열거를 사용하는 대안이되어서는 안됩니다.

나는 이것이 OO가 아닌 언어에서 더 유용하다고 생각합니다. 여기서 약간 다른 방식으로 무언가를 수행 해야하는 하나의 기능이있을 수 있으며 수행 방법을 결정하는 방법은 매개 변수 값을 기반으로합니다. OOP 세계에서는 함수에 과부하가 걸리지 만, 가능하지 않은 경우 여러 플래그 (또는 여러 값, 전달 여부)가 전달됩니다.

좀 더 읽기 쉽다고 생각합니다. 그러나 다른 사람들이 언급했듯이 많은 매개 변수를 갖는 것은 코드 냄새이므로 C #과 같은 객체 지향 언어에서는 이것을 많이 사용하지 않습니다.