모든 함수 / 메소드 인수를 새 줄에 나열하는 것은 좋지 않은 이유와 그 이유는 무엇입니까?

나는 함수를 호출 할 때마다 인수를 새로운 줄에 넣는 사람과 함께 일합니다.

aFunction(
    byte1,
    short1,
    int1, 
    int2,
    int3,
    int4,
    int5
) ;

코드가 너무 작지 않다는 것을 의미하기 때문에 매우 성가시다. 그래서 실제로 논리를 이해하려면 더 많이 스캔해야합니다. 이것이 실제로 나쁜 습관인지 아닌지 알고 싶습니다. 그렇다면 어떻게하지 말라고 설득 할 수 있습니까?

그것은 당신이 좋아하거나 좋아하지 않을 코딩 지침 일뿐입니다. 중요한 것은 당신과 당신의 동료가 그것을 사용하는지에 동의한다는 것입니다.

가독성을 높이는 가장 좋은 방법은 인수 수를 제한하는 것입니다.

그것은 선호의 문제입니다. 각 매개 변수를 문서화하거나 변수가 길고 변수가 많은 복잡한 함수 호출의 경우이 방법이 좋습니다.

예를 들면 다음과 같습니다.

do_complex_op(
      0, //Starting state, always 0, ask Joe why
      X, //X-coord of thingy
      y, //Y-coord of thingy
      73, //in this case, we don't want to use Z but want constant 
      dlogMessageTitle, //message for dialogue title
      dlogMessageText, //message for dialogue contents, don't care about this.
      SomethingIP, //IP of something-or-other server, can be NULL, won't crash.
      someObject.childObject.getValue(key1).HVAL, //very long path to HVAL
      someObject.childObject.getValue(key1).LVAL, //very long path to LVAL
      this.parentWindow.owner.mainTextBox.text.value.trim, //get the trimmed text, untrimmed text causes weird output
      pvrMainSettingForLongBlahs.getObjectByPath(somePath),
      pvrMainSettingForLongBlahs.K_TCA_UPPER_LIMIT,
      pvrMainSettingForLongBlahs.K_ENDPOINT_COMPLIANCE_LEVEL,
 );

명명 된 매개 변수를 허용하는 언어의 경우 매개 변수 이름을 사용하는 경우 더 일반적입니다 (예 : PL / SQL에 있음).

PKG_SOME_TEST_CODE.FN_DO_SOMETHING( in_text => 'test text',
                                    in_id => v_id,
                                    in_ref_id => v_ref_id,
                                    out_array_for_storage => v_bArray); 

그러나 함수 호출이 단순하고 너무 많은 매개 변수가 아닌 경우 다음과 같이 성 가실 수 있습니다.

setColour (
    r,
    g,
    b
 );

나는 읽기가 훨씬 쉽다.

 setColour(r,g,b);

@ammoQ의 경우 :

rc=a(b,c(d,e(f)))

rc=a(
     b,
     c(
       d,
       e(
         f
        )
      )
    )

일상적인 스타일보다 우월하다는 것이 긍정적으로 입증 될 수 없다면, 드문 IMO 는 나쁜 습관입니다. “맛있는 것”은 대부분의 프로그래머에게 필요한 것보다 읽기 어려운 코드를 작성하는 데 대한 핑계입니다. 언젠가는 그 스타일에 익숙하지 않은 가난한 영혼이 그 코드를 유지해야하기 때문입니다.

드문 일임을 증명하는 것은 비교적 쉬운 일이며, MSDN 또는 유사한 사이트에서 예제 소스를 보여주고, 큰 오픈 소스 코드 기반을 보여줍니다. 코드 미화 기의 출력을 보여줍니다. 의 다른 everbody 방법 궁극적으로 보여 당신의 팀이 그 일을한다. 누군가가 너무 완고해서 나쁜 스타일을 받아들이지 마십시오.

글쎄, 여기에 약간의 미끼가 있습니다. 나는 대중적인 일을했다고 비난 한 적이 없다. 일이 한 줄에 맞는다면, 한 줄에 맞추십시오.

그러나 나의 주요 관심사는 코드가 "못생긴"것인지 "예쁜"것인지에 관한 것이 아니다. 저의 주요 관심사는 실수없이 이해하고 변경하는 것이 얼마나 쉬운 지입니다.

논쟁이 길고 많은 것이 있다면, 별도의 줄에 두지 않겠습니까? 내 생각에 그것들이 무엇인지 더 쉽게 볼 수 있고 필요한 경우 쉽게 바꿀 수 있습니다. 또한 원하는 경우 각 인수에 의견을 첨부 할 수있는 공간을 제공합니다.

또한 함수에 인수를 추가하거나 제거하면 실수가 발생할 가능성을 최소화하고 싶습니다. 이는 인수 목록의 끝에서 시작하는 것보다 발생할 가능성이 높습니다. 따라서 줄 끝에서 끝보다 쉼표 (,)를 사용하는 것이 좋습니다. 그런 다음 예를 들어 목록 끝에 인수를 제거하거나 추가하려는 경우 한 줄 편집입니다. 나는 모든 줄의 끝에 가야하지만 마지막은 괄호로 끝나야하는 쉼표로 바이올린을 사용할 필요가 없습니다.

그래서 (소년, 나는 이것을 위해 화를 낼 것입니다) 나는 다음과 같이 씁니다 :

nameOfFunction(firstArgument
    , secondArgument // optional comment
       ...
    , lastArgument   // optional comment
    );

5 개에서 20 개의 인수를 가진 함수가있을 때 함수는 한 번에 그 방법을 얻지 못했습니다. 시간이 지남에 따라 커지면서 많은 수정 작업이있었습니다. 편집이 완료되지 않은 경우 구문 오류 또는 버그입니다. 그래서 나는 이것이 예쁘다고 주장하지 않습니다. 편집 내용을 올바르게 얻는 데 도움이된다고 주장합니다.

(그리고 대신 구조를 전달해야한다고 말하는 사람들에게는 구조를 채우고 할당 할 여분의 코드는 말할 것도없고 구조를 채우기 위해 많은 코드 줄이 필요하기 때문에 문제를 대체하는 것입니다.)

나는 그것을 부르지 않을 것이다. 내가 일한 모범 사례는 전체 호출을보기 위해 상당한 양을 가로로 스크롤하지 않는 한 함수 호출을 모두 한 줄에 두는 것입니다. 그것은 심판의 전화이지만, 이것이 당신의 조직이 확립 한 표준이 아니라면 이와 같은 모든 기능 을 넣는 것이 잘못되었다고 분명히 말할 것입니다.

그렇기 때문에 조직이 모든 프로그래머가 준수해야하는 일련의 가이드를 설정하는 것이 좋습니다. 일관성과 가독성에 관한 모든 것.

다음과 같이 쉽습니다.

• 인수를 재정렬하십시오.
• 인수를 주석 처리하거나 비활성화하십시오.
• 버전 관리 시스템에서 diff를 볼 때 변경된 인수를 정확히 확인하십시오.
• 인수를 추가 또는 제거하거나 함수 이름을 변경할 때 모든 항목을 다시 들여 쓰거나 줄 바꿈하지 마십시오. (편집기가 자동으로 들여 쓰기를해도 버전 관리 시스템의 변경 사항을 따르기가 더 어려워지면서 도움이되지 않는 공백 변경 사항을 많이 만들고 있습니다.)

함수 호출은 표준 코드 너비 (대개 80 문자, 종종 인수의 원인 :-)를 크게 초과하지 않는 한 한 줄에 있어야한다고 말하고 싶습니다.

이 스타일에는 이점이 없습니다. 주관적으로 추악하게 보이며 코드를 검색 할 때 고통 스럽습니다. 예를 들어, NULL로 전달 된 특정 매개 변수를 사용하여 함수가 호출되는지 여부를 빠르게 검색하고 확인할 수 있습니다. 모든 매개 변수가 한 줄에 있으면 시각적으로 쉽고, 이렇게 분할하면 더 어렵습니다.

함수 선언 이나 정의 에서 그 스타일을 자주 보았지만 결코 호출하지 않았습니다 (지금까지). 개별 매개 변수에 대한 주석을보다 명확하게 추가 할 수 있으므로 때때로 의미가 있습니다. 그는 그 뒤에 근본적인 이유를 알지 못하고 그 스타일을 전화에 복사 한 것처럼 보입니다. 당신은 좋은 주장을 가지고 있고, 그는 좋은 주장을하지 않는 것 같습니다. 그래서 당신은 나의 투표권을 가지고 있지만, 나는 당신이 설득해야 할 것이 아닙니다.

회사 코딩 표준에 위배됩니까?

그렇지 않다면 표준과 사람들이보고 싶어하는 것에 대한 토론을 시작하십시오. 변경하려는 항목 중 하나로이를 가져와야합니다.

이것이 유용하지 않다고 생각 하는 이유 에 대해 충분히 토론 하고 희망적으로 하루를 이길 것입니다. 당신은 당신의 동료가 자신의 길이 결국 최고라고 확신 할 수 있다는 것을 결코 알지 못합니다.)

업데이트 된 표준을 얻은 후에는 모든 사람이 코딩해야하는 내용이 문서화되므로 동료가이 작업을 계속하면 코드 검토에서 표준을 높일 수 있습니다.

펑키하게 보일 수 있지만 코드 작업이 쉬워집니다. 리팩토링하는 동안 개별 인수를 매우 쉽게 주석 처리하고 실제로 항목을 삭제하기 전에 리 팩터를 확인할 수 있습니다. 주석을 달고 유형을 아주 쉽게 대체 할 수도 있습니다.

다음보다 읽기가 더 쉽습니다.

int f(int, int, int,
      char, double, int
      X const&, Y)
{}

나는 당신이 보여주는 것만 큼 극단적이지는 않았습니다 (매개 사용하지 않는 매개 변수에 이름이 없기 때문에). 각 매개 변수를 자체 라인으로 분할하거나 전혀 분할하지 않는 습관에 빠져 들었습니다.

중요한 부분은 코드를 표준 80col 디스플레이에 인쇄하거나 표시 할 수 있으며 여전히 읽을 수 있다는 것입니다.

이와 같은 것에 대해 프로그래머로부터 정직한 답변을 얻는 경우는 거의 없습니다. 모든 사람들은 자신이하고 싶은 것과 싫어하는 것에 대답 할 것입니다. 진실은, 우리 모두가 때때로 어려움을 겪는 것처럼, 여기서 유일한 "나쁜 습관"은 당신 자신의 유연성이 없다는 것입니다.

실제로 나쁜 것과 당신을 괴롭히는 것들을 구별 할 수 있으려면 자신에게 잔인하게 정직해야합니다. 사실 C / C ++ 및 유사한 언어에서는 코드의 이해에 실질적인 영향을 미치는 들여 쓰기 연습을 거의 찾을 수 없습니다. 이런 종류의 것들에 대한 대부분의 토론은 사람들이 자신의 개인적 취향을 정당화하기 위해 어리 석고 불쾌한 주장을하는 사람들과 쌓여 있습니다.

내 독서에 대한 것은 ...이 질문에서 정확히 당신이 요구하는 것입니다 : 당신의 개인적인 취향을 정당화하기위한 어리 석고 불쾌한 논쟁.

솔직히 말하면 그것은 사람에 달려 있습니다. FrustratedWithForms 첫 번째 예제에서 보여주는 복잡한 함수에 대해 말하고 싶었습니다. 그렇지 않으면 큰 NO. 그런 다음 다시 이것이 코드의 IDE 기능을 임의로 적용하는 것을 선호하는 이유입니다.

"실제로 이것이 나쁜 습관인지 알고 싶습니다 ..."

예, 변수 목록이 비정상적으로 긴 경우를 제외하고는 나쁜 습관입니다. 그러나이 경우 문제는 기능 설계로 인한 것일 수 있습니다. 많은 매개 변수를 캡슐화하는 객체를 전달하지 않겠습니까?

"... 그렇다면 어떻게하지 말라고 설득 할 수 있습니까?"

그들을 묶고 쓰레기를 멈추기로 동의 할 때까지 계속 간지럽 히십시오.

왜 그런 사소한 문제에주기를 낭비하고 있습니까? 신뢰할 수있는 IDE를 시작하고 파일을 열고 다시 포맷하십시오. 짜잔! 당신이 원하는 어떤 형태로든 될 것입니다.

이제 중요한 문제인 vi 또는 emacs, LOL로 넘어가겠습니다.

논쟁이 한 줄에 들어가면 그렇게하십시오. 그렇지 않은 경우 한 줄에 하나의 인수 만 있으면 가독성이 좋아집니다.

foo(arg1, arg2, arg3, arg4, arg5)

vs.

foo(
    arg1=arg1,
    arg2=arg2,
    arg3=arg3,
    arg4=arg4,
    arg5=arg5,
    arg6=arg6,
    arg7=arg7
)