매개변수가 너무 많나요?[닫은]

Question

루틴에는 매개변수가 있을 수 있지만 이는 새로운 소식이 아닙니다.필요한 만큼 많은 매개변수를 정의할 수 있지만 너무 많으면 루틴을 이해하고 유지하기가 어려워집니다.

물론 해결 방법으로 구조화된 변수를 사용할 수 있습니다.모든 변수를 단일 구조체에 넣고 루틴에 전달합니다.실제로 구조를 사용하여 매개변수 목록을 단순화하는 것은 Steve McConnell이 설명하는 기술 중 하나입니다. 코드 완성.그러나 그가 말했듯이 :

주의 깊은 프로그래머는 논리적으로 필요한 것 이상으로 데이터를 묶는 것을 피합니다.

따라서 루틴에 매개변수가 너무 많거나 구조체를 사용하여 큰 매개변수 목록을 위장한다면 아마도 뭔가 잘못된 것입니다.즉, 커플링을 느슨하게 유지하지 않는 것입니다.

내 질문은, 언제 매개변수 목록이 너무 크다고 생각할 수 있나요? 매개변수가 5개 이상이면 너무 많은 것 같아요.어떻게 생각하나요?

Answer 1

자유 언론에 대한 첫 번째 수정 보장에도 불구하고 규제 할 수있는 것만 큼 음란 한 것이 언제입니까? 포터 스튜어트 판사에 따르면, "내가 볼 때 알아요." 여기에도 마찬가지입니다.

답변은 프로젝트의 크기와 범위에 따라 변경 될뿐만 아니라 모듈 수준까지 변경되는 것 같아요. 방법이 무엇을하고 있는지 또는 클래스가 표현 해야하는 것에 따라, 2 인수가 너무 많고 너무 많은 커플 링의 증상 일 가능성이 있습니다.

나는 처음에 질문을하고, 당신의 질문을 당신만큼이나 당신의 질문에 자격을 갖추면서, 당신은 정말로이 모든 것을 알고 있다고 제안합니다. 여기서 가장 좋은 솔루션은 단단하고 빠른 숫자에 의존하는 것이 아니라 동료들 사이의 디자인 리뷰 및 코드 리뷰를 찾아 응집력이 낮고 결합이 빡빡한 영역을 식별하는 것입니다.

동료들에게 당신의 일을 보여주는 것을 두려워하지 마십시오. 당신이 두려워한다면, 그것은 아마도 당신의 코드에 문제가 있다는 것이 더 큰 신호 일 것입니다. 이미 알고 있습니다.

Answer 2

일부 매개 변수 중 일부가 중복되는 경우 함수는 너무 많은 매개 변수를 가질 수 있습니다. 모든 매개 변수를 사용하는 경우 함수는 올바른 수의 매개 변수를 가져야합니다. 자주 사용되는 기능을 취하십시오.

HWND CreateWindowEx
(
  DWORD dwExStyle,
  LPCTSTR lpClassName,
  LPCTSTR lpWindowName,
  DWORD dwStyle,
  int x,
  int y,
  int nWidth,
  int nHeight,
  HWND hWndParent,
  HMENU hMenu,
  HINSTANCE hInstance,
  LPVOID lpParam
);

이는 12 개의 매개 변수 (x, y, w 및 h를 사각형으로 묶는 경우 9)이며 클래스 이름에서 파생 된 매개 변수도 있습니다. 이것을 어떻게 줄일 수 있습니까? 그 수를 포인트로 줄이고 싶습니까?

매개 변수의 수가 당신을 괴롭히게하지 말고, 논리적이고 잘 문서화되어 있는지 확인하고 Intellisense^* 도와주세요.

^* 다른 코딩 보조원이 가능합니다!

Answer 3

~ 안에 깨끗한 코드, Robert C. Martin 은이 주제에 4 페이지를 바쳤습니다. 여기에 요점이 있습니다.

함수에 대한 이상적인 인수는 0 (niladic)입니다. 다음은 하나 (Monadic)가 온다. 가능한 경우 세 가지 논쟁 (Triadic)을 피해야합니다. 3 개 이상의 (폴리 아딕)은 매우 특별한 정당화가 필요하며 어쨌든 사용해서는 안됩니다.

Answer 4

과거에 작업 한 일부 코드는 너무 많은 매개 변수를 전달하지 않기 위해 글로벌 변수를 사용했습니다.

제발 그렇게하지 마십시오!

(대개.)

Answer 5

서명의 매개 변수를 정신적으로 계산하고 통화와 일치시키기 시작하면 리팩터를 리팩터 할 때입니다!

Answer 6

모든 답변에 진심으로 감사드립니다.

• (나처럼) 5개의 매개변수가 코드의 온전함에 대한 좋은 한계라고 생각하는 사람들을 찾는 것은 약간 놀랐습니다.

• 일반적으로 사람들은 3에서 4 사이의 제한이 좋은 경험 법칙이라는 데 동의하는 경향이 있습니다.사람들은 일반적으로 4개 이상의 항목을 계산하는 데 어려움을 겪기 때문에 이것은 합리적입니다.

• 처럼 밀라노 포인트들, 평균적으로 사람들은 한 번에 대략 7가지를 머릿속에 간직할 수 있습니다.하지만 루틴을 설계/유지/연구할 때 매개 변수보다 더 많은 것을 염두에 두어야 한다는 점을 잊어서는 안 된다고 생각합니다.

• 어떤 사람들은 루틴에 필요한 만큼의 인수가 있어야 한다고 생각합니다.동의합니다. 하지만 몇 가지 특정 사례(OS API 호출, 최적화가 중요한 루틴 등)에만 해당됩니다.가능할 때마다 이러한 호출 바로 위에 추상화 계층을 추가하여 이러한 루틴의 복잡성을 숨기는 것이 좋습니다.

• 건강 상태 가지다 몇 가지 흥미로운 생각 이에.그의 의견을 읽고 싶지 않다면 요약하겠습니다.간단히 말해서, 때에 따라 다르지:

  나는 이렇게 엄격하고 빠른 규칙을 만드는 것을 싫어합니다. 왜냐하면 프로젝트의 크기와 범위에 따라 답이 바뀔 뿐만 아니라 모듈 수준까지 내려가도 답이 바뀌기 때문입니다.메서드가 수행하는 작업이나 클래스가 표현해야 하는 내용에 따라 두 개의 인수가 너무 많아 결합이 너무 심하다는 증상일 가능성이 높습니다.

  여기서의 교훈은 동료에게 코드를 보여주는 것을 두려워하지 말고 그들과 토론하고 노력하는 것입니다. "응집력이 낮고 결합력이 강한 영역을 식별하세요.".

• 마침내 내 생각에는 소음이 나다 많은 부분이 Nick의 의견에 동의하고 그의 풍자적 공헌을 다음과 같이 마무리합니다. 이 시적인 비전 프로그래밍 기술에 대한 (아래 설명 참조):

  프로그래밍은 엔지니어링이 아닙니다.코드 구성은 엄격한 규칙에 비해 상황에 너무 많이 의존하는 인적 요소에 의존하기 때문에 예술입니다.

Answer 7

이 답변은 OO 언어를 가정합니다. 당신이 하나를 사용하지 않는다면-이 답변을 스크립하십시오 (이것은 언어에 대한 대답이 아닙니다.

3 개 이상의 매개 변수 (특히 고유 유형/객체)를 전달하는 경우 "너무 많은"것이 아니라 새 객체를 만들 기회가 없을 수도 있습니다.

두 가지 이상의 방법으로 전달되는 매개 변수 그룹을 찾으십시오. 심지어 그룹은 두 가지 방법으로 전달되어 새로운 객체가 있어야한다는 것을 거의 보장합니다.

그런 다음 기능을 새 개체에 리팩토링하면 코드와 OO 프로그래밍에 대한 이해가 얼마나 많은지 믿지 않을 것입니다.

Answer 8

단순한 숫자 외에 다른 고려 사항이 있는 것 같습니다. 다음은 마음에 드는 몇 가지 사항입니다.

1. 기능의 주요 목적과 논리적 관계 vs.일회성 설정

2. 단지 환경 ​​플래그인 경우 번들링이 매우 편리할 수 있습니다.

Answer 9

Alan Perlis의 유명한 프로그래밍 에피그램 중 하나 (1982 년 9 월 ACM Sigplan Normices 17 (9)에서 언급 됨)에 따르면 "매개 변수가 10 개가있는 절차가 있으면 일부는 놓쳤을 것입니다."라고 말합니다.

Answer 10

Steve McConnell에 따르면 코드 완료, 당신은해야합니다

루틴 매개 변수 수를 약 7으로 제한

Answer 11

나를 위해, 목록이 내 IDE에서 한 줄을 가로 지르면 하나의 매개 변수입니다. 눈 접촉을 깨지 않고 한 줄의 모든 매개 변수를 한 줄로보고 싶습니다. 그러나 그것은 단지 나의 개인적인 취향 일뿐입니다.

Answer 12

나는 일반적으로 5에 동의하지만, 더 필요한 상황이 있고 문제를 해결하는 가장 분명한 방법이라면 더 많이 사용합니다.

Answer 13

단기 기억의 7 가지?

1. 기능의 이름
2. 함수의 반환 값
3. 기능의 목적
4. 매개 변수 1
5. 매개 변수 2
6. 매개 변수 3
7. 매개 변수 4

Answer 14

~ 안에 최악의 5 코드 스 니펫, 두 번째는 "이것은 생성자입니다"를 확인하십시오. 37 ⋅ 4 ≈ 150 매개 변수가 있습니다.

여기에 프로그래머는이 생성자를 썼습니다. 이 생성자는 손으로 작성되었다고 결론을 내립니다. (그건 그렇고 이것은 생성자의 상단 부분 일 뿐이며 완전하지 않습니다).

Answer 15

필요한 것보다 하나 더. 나는 glib이라는 의미는 아니지만 반드시 몇 가지 옵션이 필요한 기능이 있습니다. 예를 들어:

void *
mmap(void *addr, size_t len, int prot, int flags, int fildes, off_t offset);

6 개의 논쟁이 있으며, 그들 모두는 필수적입니다. 더욱이, 그들 사이에는 번들링을 정당화하기 위해 공통된 연관성이 없습니다. 어쩌면 당신은 "struct mmapargs"를 정의 할 수 있지만 더 나빠질 것입니다.

Answer 16

에 따르면 Perl 모범 사례, 3은 괜찮고, 4는 너무 많다. 그것은 단지 가이드 라인 일 뿐이지 만 우리 가게에서 우리가 고집하려는 것입니다.

Answer 17

나는 5 개의 매개 변수로 공공 기능의 한계를 그려야한다.

IMHO, 긴 매개 변수 목록은 코드의 일부 특정 장소에서만 호출되는 개인/로컬 헬퍼 기능에서만 허용됩니다. 이러한 경우 많은 상태 정보를 전달해야 할 수도 있지만, 귀하 (또는 코드를 유지하고 모듈의 기본 사항을 이해해야하는 사람)만이 신경을 써야하기 때문에 가독성은 큰 관심사가 아닙니다. 그 기능을 부릅니다.

Answer 18

당신이 고려해야 할 관련 질문은 방법입니다 결합력 있는 일상은입니다. 많은 매개 변수는 일상 자체가 너무 많은 일을하려고한다고 말하는 냄새가 될 수 있으므로 응집력이 의심됩니다. 나는 단단하고 빠른 수의 매개 변수가 불가능하다는 데 동의하지만, 높은 응집력 루틴은 적은 수의 매개 변수를 암시 할 것이라고 생각합니다.

Answer 19

97은 옳았습니다.

덜 유연성을 잃습니다.

Answer 20

일반적인 경험 법칙으로 세 가지 매개 변수로 중지합니다. 더 이상 매개 변수 배열 또는 구성 객체를 대신 전달해야하므로 API를 변경하지 않고도 향후 매개 변수를 추가 할 수 있습니다.

Answer 21

매개 변수 목록의 길이 제한은 한 가지 더 제한입니다. 그리고 제한은 적용된 폭력을 의미합니다. 재미있게 들리지만 프로그래밍 할 때도 비폭력 할 수 있습니다. 코드가 규칙을 지시하게하십시오. 많은 매개 변수가있는 경우 기능/클래스 방법의 본문이 그것들을 사용할 수있을 정도로 커질 것입니다. 그리고 빅 코드 스 니펫은 일반적으로 리팩토링되어 작은 덩어리로 나눌 수 있습니다. 따라서 많은 매개 변수를 무료 보너스로 사용하는 것에 대한 솔루션을 얻을 수 있습니다. 작은 리팩토링 된 코드로 분할되므로 솔루션이 있습니다.

Answer 22

성능 관점에서 지적하는 한 가지는 매개 변수를 메소드로 전달하는 방법에 따라 값으로 많은 매개 변수를 전달하면 각 매개 변수를 복사 한 다음 스택에 배치해야하므로 프로그램이 느려질 것입니다.

단일 클래스를 사용하여 모든 매개 변수를 포함하는 것이 더 잘 작동합니다.

Answer 23

나에 따르면 4 개 또는 일부 고정 번호를 초과하는 경우가있을 수 있습니다. 조심해야 할 것들이 될 수 있습니다

1. 방법이 너무 많이 수행되고 있으며 리팩터가 필요합니다.
2. 컬렉션 또는 일부 데이터 구조 사용을 고려할 수 있습니다.
3. 수업 디자인을 다시 생각하십시오. 아마도 몇 가지가 지나갈 필요가 없습니다.

사용 용이성 또는 읽기 편의성 각도에서, 나는 당신이 당신의 방법 서명을 "단어 랩"해야 할 때, 당신이 무력감을 느끼고 서명을 더 작은 리드로 만들기위한 모든 노력이 아니라면 멈추고 생각해야한다고 생각합니다. 결과가 없다. 과거와 현재의 아주 좋은 도서관은 4-5 개 이상의 유모차를 사용합니다.

Answer 24

내 규칙은 전화를보고 그것이 무엇을하는지 말할 수있을 정도로 오랫동안 매개 변수를 기억할 수 있어야한다는 것입니다. 따라서 메소드를 보지 못하고 메소드의 호출로 넘어 가서 어떤 매개 변수가 너무 많은지 기억하십시오.

나에게는 약 5에 해당하지만 나는 그렇게 밝지 않습니다. 귀하의 마일리지가 다를 수 있습니다.

매개 변수를 유지하기 위해 속성이있는 객체를 생성하고 설정 한 한계를 초과하는 경우이를 전달할 수 있습니다. 마틴 파울러를 참조하십시오 리팩토링 예약 및 방법 통화에 대한 장은 더 간단하게 통화됩니다.

Answer 25

그것은 당신이 일하는 환경에 크게 의존합니다. 예를 들어 JavaScript를 사용하십시오. JavaScript에서 매개 변수를 전달하는 가장 좋은 방법은 키/값 쌍이있는 객체를 사용하는 것입니다. 이는 실제로 하나의 매개 변수 만 있음을 의미합니다. 다른 시스템에서는 스위트 스팟이 3-4입니다.

결국, 그것은 모든 것이 개인적인 취향으로 귀결됩니다.

Answer 26

나는 3에 동의 할 것입니다. 4는 가이드 라인만큼 너무 많습니다. 3 개 이상의 매개 변수를 사용하면 필연적으로 하나 이상의 작업을 수행하고 있습니다. 그 이상의 작업은 별도의 방법으로 나와야합니다.

그러나 내가 작업 한 최신 프로젝트를 살펴보면 예외가 많아지고 대부분의 경우 3 개의 매개 변수로 내려 가기가 어려울 것입니다.

Answer 27

한 루틴에 7-10 개의 매개 변수가 있다면 새 클래스에 번들링하는 것을 봅니다. 하지만 그 클래스가 getters and setters가있는 많은 들판 일뿐 아니라 새로운 클래스는 하다 셔플 값이 들어오고 나가는 것. 그렇지 않으면 차라리 긴 매개 변수 목록을 참습니다.

Answer 28

평균적으로 사람들이 한 번에 머리에 7 +/- 2 가지를 유지할 수 있다는 것은 알려진 사실입니다. 나는 그 원리를 매개 변수와 함께 사용하고 싶습니다. 프로그래머가 모두 평균 이상의 지능적인 사람들이라고 가정하면 10+가 너무 많다고 말하고 싶습니다.

BTW, 매개 변수가 어떤 식 으로든 유사한 경우 구조물이나 클래스가 아닌 벡터 나 목록에 넣습니다.

Answer 29

기능이 얼마나 자주 호출되는지에 대한 답변을 기반으로합니다.

그것이 한 번만 호출되는 init 함수라면, 걱정하는 10 개의 Parm 이상을 가져 가도록하십시오.

그것이 프레임 당 많은 시간이라고 불리는 경우, 나는 구조를 만들고 포인터를 전달하는 경향이 있습니다 (매번 구조물을 재건하지 않는다고 가정).

Answer 30

아마존 명성의 Jeff Bezos에 따르면, 두 피자: