코딩 스타일 원칙에 대한 과학적으로 엄격한 연구가 있습니까? [닫은]

코딩 스타일 원칙 (예 : 단일 종료 원칙)이 실제로 좋은가? 항상 또는 때로는? 실제로 얼마나 많은 차이가 있습니까?

당신의 의견이 무엇이든, 이것들은 분명히 주관적인 질문입니다. 아니면 그들입니까?

코딩 스타일 원칙에 대해 객관적이고 과학적으로 엄격한 연구를 시도한 사람이 있습니까?

나는 누군가가 어떻게 가독성에 대한 이중 맹검 연구를하는지 상상할 수 없지만 아마도 이중 무지가 가능할 수도있다. 주제로 연구되는 원리를 모르는 학생들과 비 프로그래머가 연구를 수행하는 것을 사용하라.

deadalnix의 의견을 반영하고 있습니다. 코드 완성 2를 읽으십시오 . 필자 (Steve McConnell)는 심도있는 코딩 스타일과 논문 및 데이터에 대한 참조에 대해 논의합니다.

나는 객관적인 결과를 낳는 주제에 관한 연구의 가능성을 크게 의심하고 있으며, 설득력있는 연구를 보여줄 때까지 회의적이다.

읽고 다음 특정 코딩 스타일을 것입니다 코드 작성 년 동안 한 프로그래머 분명히 그들의 정물화에서 처음으로 볼 것입니다 일부 완벽한 코딩 스타일보다 더 읽기 찾을 수 있습니다.

가장 일반적인 QWERTY 타이핑 레이아웃과 정확히 동일합니다. 인체 학 측면에서 그것이 차선책이라는 것을 쉽게 입증 할 수 있습니다. .

그러나 드보라 크 (Dvorak) 나 콜막 (Colemak)과 같은 개량 된 대안은 결코 따라 잡지 않았으며 앞으로도 그럴 것 같지 않습니다. 따라서 사람들은 더 생산적 이지 않습니다 . 그것들이 추상적 인 의미에서 우수하더라도.

또한, (이 연구의 결과를 오염시킬 수로) 프로그래밍에 아무 사전 노출 대상을 찾기 어려울 수,하지만 프로그래밍을위한 적성, 그리고이 보여 충분히 긴 기간 동안 연구에 참여하는 것입니다 것 모두 짧은 서로에게 가중 될 수있는 시간 편익 및 장기 편익…

정답은 NO입니다! `break`와`continue`는 나쁜 프로그래밍 관행입니까? 이 질문의 하위 집합이므로 그에 대한 겨우 수정 된 답변으로 시작하겠습니다 ...

break 문을 사용하지 않고 프로그램을 다시 작성할 수 있습니다 (또는 동일한 작업을 수행하는 루프 중간에서 반환). 그러나 그렇게하면 일반적으로 프로그램을 이해하기 어렵게하는 추가 변수 및 / 또는 코드 복제를 도입해야 할 수도 있습니다. 파스칼 (1960 년대 후반 프로그래밍 언어)은 특히 초보자 프로그래머에게는 매우 나빴습니다.

Kosaraju의 제어 구조 계층 구조라는 컴퓨터 과학 결과가 있습니다.이 구조는 1973 년으로 거슬러 올라가며 Knuth의 유명한 논문 에서 언급 되었습니다. 깊이의 다단계 휴식이있는 모든 프로그램을 다시 할 수 없음을 보다 휴식의 깊이와 프로그램에 n 개의 추가 변수를 도입하지 않고있다. 그러나 이것이 단지 이론적 인 결과라고 가정 해 봅시다. (몇 가지 추가 변수를 추가해야합니까?! 스택 교환에서 3K + 사용자와 그룹을 느끼기 위해 그렇게 할 수 있습니다 ...)

소프트웨어 엔지니어링 관점에서 훨씬 더 중요한 것은 1995 년 Eric S. Roberts의 Loop Exits and Structured Programming : Rebinging the Debate (doi : 10.1145 / 199688.199815) 라는 최신 논문 입니다. Roberts는 다른 사람이 수행하기 전에 수행 한 몇 가지 경험적 연구를 요약합니다. 예를 들어, CS101 유형의 학생 그룹이 배열에서 순차 검색을 구현하는 함수에 대한 코드를 작성하도록 요청 받았을 때, 연구 저자는 중단 / 복귀를 사용하여 순차에서 나가는 학생에 대해 다음과 같이 말했습니다. 요소가 발견되면 바로 검색 루프 :

[이 스타일]을 사용하여 프로그램을 시도하여 잘못된 솔루션을 만든 한 사람을 아직 찾지 못했습니다.

로버츠는 또한 다음과 같이 말합니다.

for 루프에서 명시적인 리턴을 사용하지 않고 문제를 해결하려고 시도한 학생들은 훨씬 덜 나갔습니다.이 전략을 시도하는 42 명의 학생 중 7 명만이 올바른 솔루션을 생성 할 수있었습니다. 이 수치는 20 % 미만의 성공률을 나타냅니다.

예, CS101 학생보다 경험이 많을 수 있지만 break 문을 사용하지 않고 (또는 루프 중간에서 리턴 / 가로 이동) 결국 명목상 훌륭하게 구성되어 있지만 추가 논리 측면에서 충분히 털이있는 코드를 작성합니다 "올바른"코딩 스타일의 일부 아이디어를 따르려고 할 때 누군가, 아마도 여러분 자신이 논리 버그를 넣을 것이라는 변수와 코드 복제.

그리고 return / break-type 문 외에 하나의 큰 문제가 있으므로이 질문은 나누기 문제보다 조금 더 넓습니다. 예외 처리 메커니즘은 또한 일부 출구 출구 패러다임을 위반하고 있습니다.

• http://msmvps.com/blogs/peterritchie/archive/2008/03/07/single-entry-single-exit-should-it-still-be-applicable-in-object-oriented-languages.aspx
• http://pragprog.com/magazines/2012-04/the-pragmatic-defense

따라서 기본적으로 단일 종료 (single-exit) 원칙이 오늘날에도 여전히 유용하다고 주장한 사람은 마지막 링크에 설명 된 매우 제한적인 방식으로 사용되지 않는 한 예외 처리 패러다임에 반대하는 것입니다. 이러한 지침은 기본적으로 함수에서 모든 예외를 throw ()로 제한합니다. 즉, 함수 간 예외 전파가 전혀 허용되지 않습니다. C ++와 유사한 구문으로 새로운 파스칼을 즐기십시오.

나는 "하나의 귀환 만"이라는 개념은 어디 에서 왔는가?이 사이트에 대한 일반적인 의견은 내가 여기에 게시 한 내용과 반대되는 것이므로 질문에 대해 실제로 요청한 내용을 제공하는 첫 번째 답변인데도 왜 내가 투표에 참여하지 않았는지 완전히 이해합니다. 실제 사용성 테스트에 대한 일부 정보는 단일 종료 문제에 중점을 둡니다. 나는 특히 도박 사이트에서 지식이 선입견을 방해해서는 안된다고 생각합니다. 나는 지금부터 Wikipedia 편집을 계속할 것입니다. 적어도 좋은 출처의 정보는 높이 평가되며 출처에 의해 뒷받침되는 모호하거나 잘못된 주장은 결국 금지를받습니다. 이 사이트에서는 그 반대의 결과가 나타납니다. 사실에 의해 입증되지 않은 의견이 지배적입니다. 나는 mod 가이 마지막 부분을 삭제할 것으로 기대하지만, 적어도 그 친구는 왜 당신이 나를 기고자로 영원히 잃어 버렸는지 알 것입니다.

http://dl.acm.org/citation.cfm?id=1241526

http://www.springerlink.com/content/n82qpt83n8735l7t/

http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=661092

[질문은 "예"라는 한 단어로 대답 한 것 같습니다. 그러나 나는 짧은 답변을 제공하는 것이 그 질문에 대해 "거시적"이라고 들었습니다. 내가 불쾌감을 느낀다면 중재자가 삭제할 수 있도록 답변에 플래그를 지정하십시오.]

코딩 스타일 원칙-예 : 단일 종료 원칙

여전히 단일 출구 또는 다중 출구로가는 사람들은 1960 년대 후반에도 여전히 고착되어 있습니다. 당시 우리는 구조화 된 프로그래머의 초기 단계에 있었기 때문에 그러한 토론이 중요했으며, Bohm-Jacopini 구조적 프로그램 정리의 배후에있는 모든 발견이 모든 프로그래밍 구조에 보편적으로 적용되지는 않는다는 많은 캠프가있었습니다.

그것은 오래 전에 해결 되었어야 할 것입니다. 글쎄, 그것은 (아카데미아와 업계 모두에서 정확히 40 년 동안 정확하기 위해) 정착되었지만 사람들 (절대적으로 또는 반대하는 사람들)은주의를 기울이지 않았습니다.

나머지 답변은 모두 상대적입니다 (소프트웨어에없는 것은 무엇입니까?).

• 정말 좋은거야?

예. 대부분의 경우, 대부분의 경우에 특수한 경우와 언어 별 프로그래밍 구성에 대한 경고가 있습니다.

항상 또는 때로는?

대부분의 경우

실제로 얼마나 많은 차이가 있습니까?

다릅니다.

읽을 수있는 코드와 읽을 수없는 코드 복잡성 증가 (이제 우리가 알아야 할 오류 가능성) vs 단순성 복잡성 (그리고 오류 확률이 낮음) 컴파일러에서 암시 적 반환 (예 : Pascal, Java 또는 C #)을 추가하지 않는 언어 및 기본값은 int (C 및 C ++)입니다.

결국, 키보드 뒤에 사람 / 시간으로 연마 된 기술입니다. 때로는 다음과 같이 여러 개의 return 문을 사용할 수도 있습니다 (일부 Pascal'esque 의사 코드에서).

function foo() : someType
  begin
  if( test1 == true )
  then
    return x;
  end
  doSomethignElseThatShouldnHappenIfTest1IsTrue();
  return somethingElse();
end;

의도는 명확하고 알고리즘은 작고 복잡하지 않아 단일 리턴 포인트에서 사용되는 최종 리턴 값을 보유하는 '플래그'변수의 작성을 보증하지 않습니다. 알고리즘에 오류가있을 수 있지만, 그 구조는 간단하기 때문에 오류를 감지하는 노력이 무시할 정도입니다.

때로는 그렇지 않습니다 (여기서는 C와 유사한 의사 코드 사용).

switch(someVal)
{
case v1 : return x1;
case v2 : return x2:
case v3 : doSomething(); // fall-through
case v4: // fall-through
case v5: // fall-through
case v6: return someXthingie;
...
...
default:
   doSomething(); // no return statement yet
}

여기서 알고리즘은 간단한 구조를 갖지 않으며 switch 문 (C 스타일 코드)은 알고리즘의 일부로 의도적으로 수행되거나 수행되지 않는 폴 스루 단계를 허용합니다.

알고리즘이 정확하지만 잘못 작성되었을 수 있습니다.

또는 프로그래머의 능력을 넘어서는 외부의 힘에 의해 이것은 합법적으로 필요한 알고리즘의 실제 (정확한) 표현입니다.

어쩌면 잘못되었을 수도 있습니다.

이것의 진실을 밝히려면 이전 예보다 훨씬 많은 노력 이 필요합니다 . 그리고 여기에는 내가 강력하게 믿는 것이 있습니다 (이를 뒷받침 할 공식적인 연구가 없다는 것을 상기시킵니다).

올바른 것으로 간주되는 코드 스 니펫을 가정합니다.

1. 스 니펫이 본질적으로 단순한 흐름 구조를 가진 간단한 알고리즘을 나타내는 경우 여러 개의 리턴 문이 이러한 코드 스 니펫의 가독성과 단순성을 증가시킵니다. 간단히 말해서, 나는 작은 것을 의미하지는 않지만 본질적으로 이해할 수 있거나 자기 증거를 의미합니다. 독립적 인 노력이 필요하지 않습니다 (사람들이 구토하거나 누군가의 어머니를 저주하거나 글 머리 기호를 읽을 때 총알을 삼키도록 유도하지 않습니다). )

2. 단일 리턴 명령문은 알고리즘 실행 전체에서 리턴 값이 계산되거나이를 계산하는 알고리즘의 단계가 알고리즘 구조 내의 한 위치에 그룹화 될 수있는 경우 이러한 코드의 가독성과 단순성을 증가시킵니다. .

3. 하나의 return 문은 하나 이상의 플래그 변수에 대한 할당이 필요한 경우 그러한 할당의 위치가 알고리즘 전체에 걸쳐 균일하게 위치하지 않으면 서 그러한 코드 조각의 가독성과 단순성을 감소시킵니다.

4. 리턴 문이 알고리즘에 균일하게 분산되지 않고 크기 나 구조가 균일하지 않은 상호 배타적 인 코드 블록을 구분하는 경우 여러 리턴 문이 이러한 코드 조각의 가독성과 단순성을 떨어 뜨립니다.

이것은 문제가되는 코드 스 니펫의 복잡성과 밀접한 관련이 있습니다. 그리고 이것은 순환적이고 복잡한 복잡성 측정과 관련이 있습니다. 이를 통해 다음을 관찰 할 수 있습니다.

서브 루틴 또는 함수의 크기가 클수록 내부 제어 흐름 구조가 더 크고 복잡하며 여러 개의 return 문을 사용할지 아니면 단일 return 문을 사용할 지에 대한 의문이 생길 가능성이 커집니다.

이것의 결론은 함수를 작게 유지하고 한 가지만 수행하는 것입니다 (그리고 잘하는 것). 그것들이 명목상 작은 순환 적 및 반 복잡성 메트릭스를 나타내는 경우, 그것들이 가장 정확하고 이해 가능한 과제의 구현 일뿐 아니라, 내부 구조도 비교적 자명하다.

그런 다음에 만 수면을 잃지 않고 아주 쉽고 빠르게 할 수 있으므로 어느 쪽을 선택해도 오류가 발생할 위험이 크지 않은 상태에서 단일 반환 및 다중 반환을 사용할지 여부를 결정할 수 있습니다.

이 모든 것을 살펴보고 사람들이 단일 반품이나 여러 반품 문제로 어려움을 겪을 때, 경험 부족, 어리 석음 또는 업무 윤리 부족으로 인해 깨끗한 코드를 작성하지 않고 작성하는 경향이 있기 때문입니다. 사이클로 매틱 및 헐스 테드 측정을 완전히 무시한 괴물 기능.