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

Program / 글쓴이

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

물론 구조화 된 변수를 해결 방법으로 사용할 수 있습니다. 모든 변수를 단일 구조체에 넣고 루틴에 전달하십시오. 실제로 매개 변수 목록을 단순화하기 위해 구조를 사용하는 것은 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 프로그래밍에 대한 이해에 얼마나 도움이 될지 믿지 않을 것입니다.