너무 많은 매개 변수가 있습니까? [닫은]

루틴은 매개 변수를 가질 수 있습니다. 그것은 뉴스가 아닙니다. 필요한만큼 많은 매개 변수를 정의 할 수 있지만 너무 많은 매개 변수는 일상의 이해 및 유지 보수를 어렵게합니다.

물론 구조화 된 변수를 해결 방법으로 사용할 수 있습니다. 모든 변수를 단일 구조체에 넣고 루틴에 전달하십시오. 실제로 매개 변수 목록을 단순화하기 위해 구조를 사용하는 것은 Steve Complete 에서 Code Complete 에 설명 된 기술 중 하나입니다 . 그러나 그가 말한대로 :

주의 깊은 프로그래머는 논리적으로 필요한 것 이상으로 데이터를 번들링하지 않습니다.

따라서 루틴에 매개 변수가 너무 많거나 큰 매개 변수 목록을 가장하기 위해 구조체를 사용하는 경우 뭔가 잘못되었을 수 있습니다. 즉, 커플 링을 느슨하게 유지하지 않습니다.

내 질문은 언제 매개 변수 목록을 너무 크게 고려할 수 있습니까? 나는 5 개 이상의 매개 변수가 너무 많다고 생각합니다. 어떻게 생각해?

언론의 자유를 보장하기 위해 제 1 차 개정안에도 불구하고 규제 할 수있는 것이 외설적 인 것으로 간주되는 것은 언제입니까? 포터 스튜어트 법무 장관에 따르면 "보자 마자 알아요." 여기에서도 마찬가지입니다.

대답은 프로젝트의 크기와 범위에 따라 변경 될뿐만 아니라 모듈 수준까지도 변경된다고 생각하기 때문에 강력하고 빠른 규칙을 만드는 것을 싫어합니다. 메소드가 수행하는 작업 또는 클래스가 나타내는 것으로 가정하면 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)이며 클래스 이름에서 파생 된 매개 변수도 있습니다. 이것을 어떻게 줄이겠습니까? 숫자를 더 줄이려고 하시겠습니까?

매개 변수의 수는 당신을 귀찮게하지 말고, 그냥 논리적이고 잘 문서화 확실하고 인텔리 수 있도록 ^* 당신을 도울.

^* 다른 코딩 어시스턴트도 이용 가능합니다!

에서 클린 코드 로버트 C. 마틴은 주제에 네 페이지를 할애. 요점은 다음과 같습니다.

함수에 대한 이상적인 인수 수는 0입니다 (나일론). 다음은 하나 (모나 딕)가오고 그 다음에 두 (다익)이옵니다. 가능한 경우 세 가지 주장 (삼국 법)을 피해야합니다. 3 개 이상 (다중)은 매우 특별한 타당성을 요구하므로 절대로 사용해서는 안됩니다.

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

제발 하지마!

(보통.)

서명의 매개 변수를 정신적으로 계산하고 호출과 일치시켜야하는 경우 리팩토링해야합니다.

모든 답변에 감사드립니다.

• 5와 같은 매개 변수가 코드의 완전성에 대한 좋은 제한이라고 생각하는 사람들을 찾는 것은 약간 놀라운 일이었습니다.

• 일반적으로 사람들은 3에서 4 사이의 제한이 좋은 경험이라는 데 동의하는 경향이 있습니다. 사람들이 보통 4 가지 이상의 것을 세는 데 나쁜 시간을 보내기 때문에 이것은 합리적입니다.

• 밀라노가 지적한 것처럼 , 평균적으로 사람들은 한 번에 7 개 정도의 머리를 유지할 수 있습니다. 그러나 루틴을 디자인 / 유지 관리 / 연구 할 때 매개 변수보다 더 많은 것을 명심해야한다는 것을 잊을 수 없다고 생각합니다.

• 어떤 사람들은 루틴이 필요한만큼 많은 주장을 가져야한다고 생각합니다. 동의하지만, 몇 가지 특별한 경우 (OS API 호출, 최적화가 중요한 루틴 등)에 동의합니다. 가능할 때마다 이러한 호출 바로 위에 추상화 계층을 추가하여 이러한 루틴의 복잡성을 숨길 것을 제안합니다.

• Nick 은 이것에 대해 몇 가지 흥미로운 생각 을 가지고 있습니다 . 당신이 자신의 의견을 읽고 싶지 않은 경우에, 나는 당신을 위해 요약 : 간단히 말해서, 그것은 의존한다 :

  대답은 프로젝트의 크기와 범위에 따라 변경 될뿐만 아니라 모듈 수준까지도 변경된다고 생각하기 때문에 강력하고 빠른 규칙을 만드는 것을 싫어합니다. 메소드가 수행하는 작업 또는 클래스가 나타내는 것으로 가정하면 2 개의 인수가 너무 많고 너무 많은 커플 링의 증상 일 수 있습니다.

  여기의 도덕은 동료들에게 코드를 보여주는 것을 두려워하지 말고, 그들과 토론하고, "응집력이 낮고 결합력이 낮은 영역을 식별하십시오" .

• 마지막으로, 나는 wnoise 가 Nick과 동의하고 프로그래밍 기술에 대한 이 시적 비전 (아래 주석 참조)에 대한 풍자적 기여를 마무리 짓는다 .

  프로그래밍은 엔지니어링이 아닙니다. 코드의 구성은 인간의 요소에 의존하기 때문에 예술이며, 이는 어려운 규칙의 맥락에 너무 의존합니다.

이 답변은 OO 언어를 가정합니다. 당신이 하나를 사용하지 않는다면-이 대답을 건너 뛰십시오 (즉, 이것은 언어에 독립적 인 대답이 아닙니다.

3 개 이상의 매개 변수 (특히 내장 형식 / 개체)를 전달하는 경우 "너무 많은"것이 아니라 새 개체를 만들 가능성이없는 것일 수 있습니다.

둘 이상의 메소드에 전달되는 매개 변수 그룹을 찾으십시오. 심지어 두 개의 메소드에 전달 된 그룹도 새 오브젝트가 있어야합니다.

그런 다음 기능을 새로운 객체로 리팩터링하면 코드와 OO 프로그래밍에 대한 이해에 얼마나 도움이 될지 믿지 않을 것입니다.

단순한 숫자가 아닌 다른 고려 사항이있는 것 같습니다.

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

2. 환경 플래그 일 경우 번들링이 매우 편리합니다.

Alan Perlis의 잘 알려진 프로그래밍 에피 그램 중 하나 (1982 년 9 월 ACM SIGPLAN Notices 17 (9)에 언급)는 "매개 변수가 10 개인 프로 시저가 있다면 아마도 일부를 놓쳤을 것"이라고 말합니다.

스티브 맥코넬에 따르면 코드 완료 , 당신은해야

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

나에게있어서, 목록이 내 IDE에서 한 줄을 넘으면 너무 많은 매개 변수입니다. 눈을 마주 치지 않고 모든 매개 변수를 한 줄로보고 싶습니다. 그러나 그것은 나의 개인적인 취향 일뿐입니다.

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

단기 기억의 7 가지?

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

에서 최악의 5 코드 조각 "이 생성자인가", 두 번째를 확인합니다. 37 개 이상의 ⋅ 4 ≈ 150 개 이상의 매개 변수가 있습니다.

여기 프로그래머가이 생성자를 썼습니다. [...] 당신 중 일부는 큰 생성자라고 생각할 수도 있지만 이클립스 자동 코드 생성 도구 [.] NOO를 사용했습니다. 이 생성자가 직접 작성되었다고 결론 내립니다. (이것은 생성자의 상단 부분에 불과하며 완성되지는 않았습니다).

하나 이상 필요합니다. 나는 glib을 의미하지는 않지만 반드시 몇 가지 옵션이 필요한 기능이 있습니다. 예를 들면 다음과 같습니다.

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

6 개의 논증이 있으며, 각각의 주장은 필수적입니다. 또한 번들링을 정당화하기위한 공통적 인 연결 고리가 없습니다. 어쩌면 "struct mmapargs"를 정의 할 수도 있지만, 더 나쁠 것입니다.

Perl Best Practices 에 따르면 3은 괜찮고 4는 너무 많습니다. 그것은 단지 지침 일 뿐이지 만, 우리 가게에서는 우리가 고수하려고 노력합니다.

5 개의 매개 변수에서 공용 함수에 대한 제한을 그립니다.

IMHO, 긴 매개 변수 목록은 코드의 몇 가지 특정 위치에서만 호출되는 개인 / 로컬 도우미 기능에서만 사용할 수 있습니다. 이 경우 많은 상태 정보를 전달해야 할 수도 있지만 가독성은 그다지 중요하지 않습니다 (또는 코드를 유지하고 모듈의 기본 사항을 이해해야하는 사람)만이 관심을 가져야하기 때문입니다 그 함수를 호출합니다.

고려해야 할 관련 질문 은 루틴이 얼마나 응집력 이 있는지 입니다. 많은 수의 매개 변수가 루틴 자체가 너무 많은 일을하려고하므로 응집력이 의심됨을 나타내는 냄새 일 수 있습니다. 나는 단단하고 빠른 수의 매개 변수가 불가능하다는 데 동의하지만 응집력이 높은 루틴은 적은 수의 매개 변수를 의미한다고 생각합니다.

97 소리가납니다.

더 적 으면 유연성이 떨어집니다.

나는 일반적으로 세 가지 매개 변수에서 멈 춥니 다. 이제 더 이상 매개 변수 배열 또는 구성 개체를 전달해야하므로 API를 변경하지 않고도 향후 매개 변수를 추가 할 수 있습니다.

매개 변수 목록의 길이 제한은 하나 이상의 제한입니다. 그리고 제한은 적용된 폭력을 의미합니다. 우스운 것처럼 들리지만 프로그래밍 할 때도 비폭력적일 수 있습니다. 코드가 규칙을 지시하도록하십시오. 매개 변수가 많은 경우 함수 / 클래스 메서드의 본문이이를 사용할 수있을만큼 커질 것입니다. 또한 큰 코드 스 니펫은 일반적으로 리팩터링하여 더 작은 청크로 나눌 수 있습니다. 따라서 리팩터링 된 작은 코드 조각으로 나뉘어져 있기 때문에 많은 매개 변수를 무료 보너스로 사용할 수 없습니다.

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

단일 클래스를 사용하여 모든 매개 변수를 포함하면 참조로 전달되는 단일 매개 변수가 우아하고 깨끗하며 빠르기 때문에 더 효과적입니다!

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

1. 분석법이 너무 많이 수행되므로 리팩터링해야합니다.
2. 컬렉션 또는 일부 데이터 구조 사용을 고려할 수 있습니다.
3. 수업 디자인을 다시 생각해보십시오. 일부 물건을 전달할 필요는 없습니다.

사용 편의성 또는 코드 판독 용이성에서 메소드 서명을 "워드 랩 (word wrap)"해야 할 때, 생각을 멈추고 생각해야한다고 생각합니다. 결과가 없다. 과거와 현재의 아주 훌륭한 도서관은 4-5 개 이상의 유모차를 사용합니다.

경험상, 전화를보고 그것이 무엇을하는지 알 수있을만큼 오랫동안 매개 변수를 기억할 수 있어야합니다. 따라서 메서드를 볼 수 없으면 메서드 호출로 넘어 가서 너무 많은 매개 변수를 수행하는 매개 변수를 기억하십시오.

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

매개 변수를 보유하고 설정 한 한계를 초과하는 경우 전달할 특성이있는 오브젝트를 작성할 수 있습니다. Martin Fowler의 리팩토링 책과 메소드 호출을보다 간단하게하는 장을 참조하십시오 .

작업중인 환경에 따라 크게 달라집니다. 예를 들어 javascript를 예로 들어 보겠습니다. 자바 스크립트에서 매개 변수를 전달하는 가장 좋은 방법은 키 / 값 쌍이있는 객체를 사용하는 것입니다. 실제로는 하나의 매개 변수 만 있습니다. 다른 시스템에서는 스위트 스폿이 3-4 개가됩니다.

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

3은 괜찮습니다. 4는 지침으로 너무 많습니다. 3 개 이상의 매개 변수를 사용하면 필연적으로 하나 이상의 작업을 수행하게됩니다. 하나 이상의 작업을 별도의 방법으로 분할해야합니다.

그러나 내가 작업 한 최신 프로젝트를 살펴보면 예외가 많으며 대부분의 경우 3 개의 매개 변수로 내려 가기가 어렵습니다.

하나의 루틴에 7-10 개의 매개 변수가있는 경우 새 클래스로 묶는 것을 보지만 해당 클래스가 getter 및 setter가있는 필드 일뿐이 아니라면 새 클래스는 값을 섞는 것 이외의 다른 작업 을 수행해야 합니다. 밖. 그렇지 않으면 오히려 긴 매개 변수 목록을 사용하고 싶습니다.

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

BTW, 매개 변수가 어떤 식 으로든 비슷한 경우 구조체 또는 클래스가 아닌 벡터 또는 목록에 추가합니다.

함수가 얼마나 자주 호출되는지에 대한 대답을 기반으로합니다.

한 번만 호출 된 init 함수 인 경우 관심있는 10 개 이상의 매개 변수가 필요합니다.

프레임 당 여러 번 호출되면 구조를 만들고 포인터를 전달하는 것이 더 빠르기 때문에 포인터를 전달하는 경향이 있습니다 (매번 구조체를 다시 작성하지 않는다고 가정).

아마존 명성의 제프 베조스 (Jeff Bezos)에 따르면 피자 는 두 개만 먹일 수있다 .