구조화된 프로그래밍

Structured programming
프로그래밍 패러다임

구조화 프로그래밍은 선택(if/then/else)과 반복(while/for), 블록 구조 및 서브루틴의 구조화된 제어 흐름 구조를 광범위하게 사용함으로써 컴퓨터 프로그램의 명확성, 품질 및 개발 시간을 향상시키는 것을 목적으로 하는 프로그래밍 패러다임입니다.

1950년대 후반에 ALGOL 58과 ALGOL 60 프로그래밍 [1]언어가 등장하면서 등장하였으며, 후자는 블록 구조를 지원하였다.이 인기에 기여 요인과 폭넓은 동의에 학계의 및 실천가들 사이에서 나중에 첫번째, 현재는 구조화 프로그램 정리로 1966,[2]으로 알려지고 있는 것이다를 발견해서 1968년에 영향력 있는"정책 고려 사항려면 불공정한 가다"공개 서한의 네덜란드어 컴퓨터 과학자 에츠허르 Dijkstra,에 의해 출판을 포함한다.who는 "구조화된 프로그래밍"[3]이라는 용어를 만들었습니다.

구조화된 프로그래밍은 예외 처리를 수행해야 하는 경우 등 일부 특정 상황에서 더 명확한 프로그램을 허용하는 편차와 함께 가장 자주 사용됩니다.

요소들

제어 구조

구조화된 프로그램 정리에 따라 모든 프로그램은 제어 구조로 구성됩니다.

  • "시퀀스": 순서대로 실행되는 명령문 또는 서브루틴.
  • "선택" 프로그램 상태에 따라 하나 또는 여러 개의 문이 실행됩니다.이것은 보통 등의 키워드로 표현됩니다.조건부 문에는 적어도1개의 참 조건이 있어야 하며 각 조건에는 최대 1개의 출구 포인트가 있어야 합니다.
  • "반복": 프로그램이 특정 상태에 도달하거나 컬렉션의 모든 요소에 작업이 적용될 때까지 문 또는 블록이 실행됩니다.이것은 보통 , , 또는 와 같은 키워드로 표현됩니다.대부분의 경우, 각 루프는 1개의 엔트리 포인트만 가질 것을 권장합니다(원래 구조 프로그래밍에서는 1개의 출구 포인트만 사용할 것을 권장합니다).
  • "Recursion(재귀)". 종료 조건이 충족될 때까지 반복 호출하여 문이 실행됩니다.실제로는 반복 루프와 비슷하지만 재귀 루프는 계산 효율이 더 높을 수 있으며 캐스케이드 스택으로 다르게 구현됩니다.
NS 다이어그램(파란색)과 흐름도(녹색)를 사용하여 시퀀스, 선택 및 반복의 3가지 기본 패턴을 그래픽으로 표현합니다.

서브루틴

서브루틴: 프로시저, 함수, 메서드, 서브프로그램 등의 콜 가능 단위를 사용하여 시퀀스를 단일 스테이트먼트로 참조할 수 있습니다.

블록

블록은 스테이트먼트 그룹을 하나의 스테이트먼트처럼 취급할 수 있도록 하기 위해 사용됩니다.블록 구조화 언어에는 if-statement를 괄호로 묶은 것과 같은 형식적인 방법으로 구조체를 둘러싸는 구문이 있습니다.if..fiALGOL 68 또는 코드 섹션의 괄호로 묶음BEGIN..ENDPL/I 및 Pascal에서처럼 공백 들여쓰기 또는 물결 괄호{...}C와 그 이후의 많은 언어들.

구조화된 프로그래밍 언어

절차적 프로그래밍 [citation needed][clarification needed]언어와 같은 것을 사용하는 것이 선호되지만, 구조화된 프로그래밍을 모든 프로그래밍 언어로 수행할 수 있습니다.구조화 프로그래밍에 처음 사용된 언어로는 ALGOL, PL/I 및 Ada가 있지만, 그 이후 대부분의 새로운 절차형 프로그래밍 언어에는 구조화 프로그래밍을 장려하는 기능이 포함되어 있으며, 때로는 비구조화 프로그래밍을 더욱 어렵게 하기 위해 의도적으로 기능(특히 GOTO)을 생략하기도 합니다.구조화된 프로그래밍(모듈러[citation needed] 프로그래밍이라고도 함)은 보다 효율적이고 이해하기 쉽고 수정하기 쉽도록 작성 중인 프로그램에 논리 구조를 적용합니다.

역사

이론적 기초

구조화된 프로그램 정리는 구조화된 프로그래밍의 이론적 기초를 제공한다.프로그램을 조합하는 세 가지 방법(시퀀스, 선택 및 반복)은 계산 가능한 함수를 표현하기에 충분하다고 명시되어 있습니다.이 관찰은 구조화된 프로그래밍 움직임에서 비롯되지 않았습니다. 이러한 구조는 튜링 기계의 작동뿐만 아니라 중앙 처리 장치의 명령 주기를 설명하기에 충분합니다.따라서 프로세서는 메모리로부터 읽어낸 명령어가 구조화 프로그램의 일부가 아니더라도 항상 이러한 의미에서 구조화 프로그램을 실행하고 있습니다.그러나 저자들은 보통 1966년 Böhm과 Jacopini의 논문에 그 결과를 돌린다. 아마도 Dijkstra가 [4]이 논문을 직접 인용했기 때문일 것이다.구조화된 프로그램 정리는 유용하게 구조화된 프로그램을 작성하고 분석하는 방법을 다루지 않는다.이러한 문제는 1960년대 후반과 1970년대 초반에 다루어졌으며, Dijkstra, Robert W.가 주요 공헌을 했다. 플로이드, 토니 호어, 올레 조한 달, 그리고 데이비드 그리스가 있다.

토론.

구조화 프로그래밍의 얼리어답터인 P. J. Plauger는 구조화 프로그램 정리에 대한 자신의 반응을 다음과 같이 설명했다.

우리는 이 흥미로운 뉴스를 구성되지 않은 어셈블리 언어 프로그래머들의 코앞에서 흔들었다. 그들은 계속해서 뒤틀린 논리를 내뱉으며 '나는 당신이 이것을 구성하지 못할 것이라고 장담합니다.'Böhm과 Jacopini에 의한 증명이나 구조화된 코드 작성에 대한 우리의 반복적인 성공이 그들이 스스로를 [5]설득할 준비가 된 하루 빨리 그들을 데려오지 않았다.

도날드 크누스는 프로그램이 입증 가능성을 염두에 두고 작성되어야 한다는 원칙을 받아들였지만 GOTO 선언을 폐지하는 것에 반대하여 2018년 현재 자신의 프로그램에서 [6]계속 사용하고 있습니다.1974년 논문 "Goto Statements를 사용한 구조화된 프로그래밍"[7]에서 그는 직접 점프가 입증 가능성을 희생하지 않고 더 명확하고 효율적인 코드로 이어진다고 믿는 예를 들었다.Knuth는 보다 느슨한 구조적 제약을 제안했다.프로그램의 흐름도는 모든 분기가 왼쪽에 있고 모든 분기가 오른쪽에 있으며 서로 교차하는 분기가 없는 상태로 그릴 수 있어야 합니다.컴파일러와 그래프 이론에 정통한 많은 사람들은 축소 가능한 흐름[when defined as?] [who?]그래프만 허용하는 것을 지지해 왔다.

구조화 프로그래밍 이론가들은 IBM 연구원 Harlan Mills가 구조화 프로그래밍 이론에 대한 그의 해석을 뉴욕 타임즈 연구 파일을 위한 색인 시스템 개발에 적용한 후 1970년대에 주요 협력자를 얻었다.Dijkstra는 Mills의 해석이 출판된 [citation needed]작업과 다르다는 것을 비판했지만, 이 프로젝트는 훌륭한 엔지니어링 성공이었고 다른 회사의 매니저들은 구조화된 프로그래밍을 채택하는 것을 지지하기 위해 이 프로젝트를 인용했습니다.

1987년까지도 컴퓨터 과학 저널에서 구조화된 프로그래밍에 대한 문제를 제기하는 것이 여전히 가능했다.프랭크 루빈은 그 해 "해로움으로 간주되는 GOTO"[8]라는 제목의 공개 서한을 통해 그렇게 했다.루빈과 그에 대한 다른 작가들의 양보를 신랄하게 비판하는 다이크스트라의 답변 등 수많은 반대가 뒤따랐다.

결과

20세기 말까지, 거의 모든 컴퓨터 과학자들은 구조화된 프로그래밍의 개념을 배우고 적용하는 것이 유용하다고 확신했다.원래 프로그래밍 구조가 부족했던 FORTRAN, COBOL 및 BASIC과 같은 고급 프로그래밍 언어들이 이제 그것들을 가지고 있다.

공통 편차

goto는 현재 선택(if/then/else)과 반복(while/for)의 구조화된 구조로 대체되었지만 순수하게 구조화된 언어는 거의 없다.많은 언어에서 볼 수 있는 가장 일반적인 편차는 서브루틴에서 조기 종료하기 위해 return 문을 사용하는 것입니다.따라서 구조화된 프로그래밍에 필요한 단일 종료 지점이 아닌 여러 종료 지점이 생성됩니다.순수하게 구조화된 프로그래밍에서 어색한 사례를 다루는 다른 구성도 있습니다.

조기 종료

구조화 프로그래밍에서 가장 일반적인 편차는 함수 또는 루프를 조기에 종료하는 것입니다.기능 수준에서 이것은return진술.루프 레벨에서는, 이것은break스테이트먼트(루프 삭제) 또는continuestatement(현재 반복을 반복하고 다음 반복으로 진행합니다).구조화된 프로그래밍에서는 분기 또는 테스트를 추가하여 복제할 수 있지만 중첩된 코드에서 반환되는 경우에는 상당히 복잡해질 수 있습니다.C는 이러한 구성의 초기이자 두드러진 예입니다.일부 새로운 언어에는 "레이블 브레이크"가 있어 가장 안쪽의 루프에서 벗어날 수 있습니다.또한 예외는 조기 종료를 허용하지만 추가적인 결과를 초래하므로 아래에서 처리한다.

여러 가지 이유로 여러 개의 출구가 발생할 수 있습니다.대부분 서브루틴이 더 이상 할 일이 없거나(값을 반환하면 계산이 완료), 서브루틴을 계속할 수 없는 "예외적인" 상황이 발생하여 예외 처리가 필요한 경우가 대부분입니다.

조기 종료 시 가장 일반적인 문제는 할당된 메모리가 할당 해제되지 않거나 열려 있는 파일이 닫히지 않아 메모리 누수 또는 리소스 누수가 발생하는 등 청소 또는 최종 스테이트먼트가 실행되지 않는 것입니다.이러한 작업은 각 반품 사이트에서 수행해야 합니다.이는 취약하고 버그가 발생하기 쉽습니다.예를 들어, 나중에 개발하면 개발자에 의해 리턴 스테이트먼트가 간과될 수 있으며 서브루틴의 마지막에 실행되어야 하는 액션(예를 들어 트레이스 스테이트먼트)이 모든 경우에 수행되지는 않을 수 있습니다.표준 Pascal 및 Seed7과 같이 반환문이 없는 언어에는 이 문제가 없습니다.

대부분의 현대 언어는 이러한 [9]유출을 방지하기 위해 언어 수준의 지원을 제공합니다. 자세한 내용은 리소스 관리에서 확인하십시오.일반적으로 이것은 언바인드 보호를 통해 이루어집니다.이 보호는 실행이 블록을 종료할 때 특정 코드가 확실하게 실행되도록 보장합니다.이것은 정리 블록과 cleanup block을 갖는 구조화된 대체 수단입니다.goto이것은 주로 로 알려져 있습니다.try...finally,예외 처리의 일부로 간주됩니다.복수인 경우return소개문try...finally,이상하게 보일 수도 있어요.자원 관리를 캡슐화하기 위한 다양한 기술이 존재합니다.대체 접근법은 주로 C++에서 볼 수 있는 Resource Acquisition Is Initialization입니다.이 접근법은 함수 종료 시 일반 스택 언바인딩(가변 할당 해제)을 사용하여 로컬 변수의 디스트럭터를 호출하여 리소스 할당을 해제합니다.

켄트 벡, 마틴 파울러, 그리고 공동 저자들은 그들의 리팩터링 책에서 내포된 조건들이 가드 절에 의해 전제되는 여러 개의 출구를 사용하는 특정한 유형의 평평한 구조보다 이해하기 어려울 수 있다고 주장했다.그들의 2009년 책에는 "출구점 하나는 정말 유용한 규칙이 아니다.명확성이 주요 원칙입니다.하나의 출구점이 있는 방법이 더 명확할 경우 하나의 출구점을 사용하고, 그렇지 않을 경우 사용하지 마십시오.이들은 중첩된 조건부만으로 구성된 함수를 일련의 가드된 리턴(또는 던지기) 문으로 변환하기 위한 요리책 솔루션을 제공하고, 그 뒤에 하나의 가드되지 않은 블록이 뒤따른다.이것은 일반적인 케이스의 코드를 포함하도록 의도된 것이며, 가드된 문장은 덜 일반적인 것([10]또는 오류가 있는 것)을 다루도록 되어 있다.Herb Sutter와 Andrei Alexandrescu도 2004년 C++ 팁북에서 싱글 출구 포인트가 쓸모없는 요건이라고 [11]주장합니다.

David Watt는 2004년 교과서에서 "싱글 엔트리 멀티 출구 제어 흐름이 종종 바람직하다"고 쓰고 있습니다.시퀀서에 대한 테네트의 프레임워크 개념을 사용하여 와트는 현대 프로그래밍 언어에서 발견되는 제어 흐름 구조를 균일하게 설명하고 다중 출구 제어 흐름의 맥락에서 특정 유형의 시퀀서가 다른 것보다 더 나은 이유를 설명하려고 시도합니다.Watt는 독자가 점프의 대상이 되는 실제 라벨이나 주소를 찾아 조사할 때까지 점프의 대상이 프로그램 독자에게 직접 설명되지 않기 때문에 제한되지 않은 gotos(점프 시퀀스)는 나쁘다고 쓰고 있습니다.이와는 대조적으로, Watt는 리턴 시퀀서의 개념적 의도는 대상을 조사할 필요 없이 자체 컨텍스트에서 명확하다고 주장합니다.Watt는 이스케이프 시퀀서로 알려진 시퀀서의 클래스는 "텍스트로 둘러싸인 명령 또는 프로시저의 실행을 종료하는 시퀀서"로 정의되며 루프로부터의 브레이크(멀티 레벨 브레이크 포함)와 리턴 스테이트먼트를 모두 포함한다고 쓰고 있습니다.Watt는 또한 점프 시퀀서(gotos)가 C와 같은 언어에서 다소 제한되고 있지만, 여기서 타겟은 내부 로컬 블록 또는 포괄적인 외부 블록이어야 하지만, 그 제한만으로는 C의 자기 기술에서 gotos의 의도를 만들기에 충분하지 않고 여전히 "스파게티 코드"를 생성할 수 있다고 지적합니다.또한 Watt는 예외 시퀀서가 이스케이프 및 점프 시퀀서와 어떻게 다른지 조사합니다.이것에 대해서는,[12] 이 문서의 다음의 항에서 설명합니다.

위와 대조적으로, Bertrand Meyer는 그의 2009년 교과서에서 다음과 같은 지시를 썼다.break그리고.continue'오래된 것일 뿐'goto양가죽을 쓰고 있다"며 사용을 [13]강력히 권고했다.

예외 처리

소프트웨어 개발자인 Jim Bonang은 Ariane 501 재해에 따른 코딩 오류를 근거로 함수의 예외는 모두 단일 출구 패러다임을 위반한다고 주장하며 모든 절차 간 예외를 금지해야 한다고 제안합니다.Bonang은 모든 단일 출구에 적합한 C++는 다음 행에 따라 작성되어야 한다고 제안합니다.

부울 마이체크1() 던지다() {   부울 성공. = 거짓의;   해라 {     // 예외가 발생할 수 있는 작업을 수행합니다.     한다면 (!마이체크2()) {       던지다 Some Internal Exception(일부 내부 예외)();     }     // 위와 유사한 기타 코드.     성공. = 진실의;   } 또 만나 (...) {     // 모든 예외가 발견되어 기록됩니다.   }   돌아가다 성공.; }

피터 리치도 원칙적으로 단 한 명이라도throw의 직전에return함수는 단일 출구 원칙을 위반하지만, Dijkstra의 규칙은 예외 처리가 프로그래밍 언어에서 패러다임이 되기 전에 작성되었다고 주장하므로, 그는 단일 반환점 외에 임의의 수의 슬로우 포인트를 허용할 것을 제안한다.그는 단일 출구를 만들기 위해 예외를 포장하는 솔루션은 내포 깊이가 높아 이해하기 어렵고 심지어 화물 컬트 [14]사고에 관여하는 예외를 지원하는 프로그래밍 언어에 이러한 솔루션을 적용하자고 제안하는 사람들을 비난하기도 한다고 지적합니다.

또한 David Watt는 시퀀서 프레임워크에서 예외 처리를 분석합니다(이전 섹션에서 조기 종료에 대해 소개했습니다).와트는 비정상적인 상황(일반적으로 산술 오버플로우 또는 파일을 찾을 수 없는 것과 같은 입출력 장애)은 "일부 낮은 수준의 프로그램 유닛에서 감지되지만 핸들러가 높은 수준의 프로그램 유닛에서 더 자연스럽게 위치하는" 오류의 일종이라고 지적합니다.예를 들어, 프로그램에는 파일을 읽기 위한 호출이 여러 개 포함되어 있을 수 있지만 파일을 찾을 수 없을 때 실행하는 액션은 프로그램에 대한 해당 파일의 의미(목적)에 따라 다르므로 이 비정상적인 상황에 대한 처리 루틴을 낮은 수준의 시스템 코드에서 찾을 수 없습니다.Watts는 또한 싱글 출구 구조화된 프로그래밍이나 심지어 (멀티 출구) 리턴 시퀀서로 인해 상태 플래그 테스트를 호출자에게 도입하면 "어플리케이션 코드가 상태 플래그 테스트에 의해 혼란스러워지는 경향이 있다"며 "프로그래머가 상태 플래그 테스트를 잊어버리거나 게을리 할 수 있다"고 지적했다.실제로 상태 플래그로 나타나는 비정상적인 상황은 기본적으로 무시됩니다."그는 상태 플래그 테스트와 달리 예외는 반대되는 기본 동작을 가지며 프로그래머가 어떤 식으로든 예외를 명시적으로 처리하지 않는 한, 아마도 의도적으로 무시하기 위한 코드를 추가함으로써 프로그램이 종료된다는 점에 주목한다.이러한 주장을 바탕으로 Watt는 점프 시퀀서 또는 이스케이프 시퀀서(이전 섹션에서 설명)는 위에서 설명한 [15]시멘틱스를 가진 전용 예외 시퀀서만큼 적합하지 않다고 결론지었다.

Louden과 Lambert의 교과서는 예외 처리가 다음과 같은 구조화된 프로그래밍 구조와 다르다는 것을 강조한다.while컨트롤 전송이 실제 전송이 이루어지는 지점과는 다른 포인트에서 설정되기 때문에 루프가 발생합니다.실제로 전송이 이루어지는 시점에서는 제어가 실제로 [16]전송될 것이라는 통사적 징후는 없을 수 있습니다."컴퓨터 공학 교수인 Arvind Kumar Bansal은 또한 예외 처리를 구현하는 언어에서는 다음과 같은 구조도 제어합니다.for예외 없이 싱글 패리티 속성을 가진 경우 예외는 존재하지 않습니다.이는 예외로 인해 제어 구조의 어느 부분에서든 조기 종료가 발생할 수 있기 때문입니다.예를 들어 다음과 같습니다.init()에 예외를 두다for (init(); check(); increm())그러면 check() 이후의 통상적인 출구 포인트에 [17]도달하지 않습니다.Westley Weimer와 George Necula는 다른 사람의 여러 선행 연구(1999-2004)와 자신의 결과를 인용하면서 예외의 중요한 문제는 "프로그래머가 추론하기 어려운 숨겨진 제어 흐름 경로를 만드는 것"[18]이라고 썼다.

OpenMP 등 병렬 컴퓨팅에 중점을 둔 일부 현대 프로그래밍 환경에서는 코드를 단일 출구 포인트로 제한할 필요가 있습니다.OpenMP의 다양한 병렬 구성, 예를 들어parallel do병행구조의 내부로부터 외부로의 조기 출구는 허가하지 않습니다.이 제한에는 모든 종류의 출구가 포함됩니다.breakC++ 예외에 대해 설명하지만 점프 타깃이 C++[19] 내에 있는 경우 이 모든 것이 병렬 구성 내에서 허용됩니다.

다중 엔트리

상세 정보:코루틴

드물게 하위 프로그램에서 여러 항목을 입력할 수 있습니다.이것은 보통 코루틴(또는 제너레이터/세미코루틴)에 재진입하는 것으로, 여기서 서브프로그램이 제어(및 가능한 값)를 발생시키지만, 그 후에 중단한 곳에서 재개할 수 있습니다.이러한 프로그래밍에는 특히 스트림(특히 입력/출력), 상태 시스템 및 동시성 등 여러 가지 일반적인 용도가 있습니다.코드 실행의 관점에서 볼 때, 코루틴에서 산출하는 것은 서브루틴에서 반환하는 것보다 구조화된 프로그래밍에 가깝습니다.서브루틴이 실제로 종료된 것은 아니며, 다시 호출되었을 때 계속됩니다.이것은 조기 종료가 아닙니다.단, coroutines는 서브루틴의 단일 콜스택이 아니라 여러 서브프로그램이 실행 상태를 가지므로 다른 형태의 복잡성이 발생합니다.

이 경우 프로그램 상태(변수 값 등)가 초기화되지 않았거나 모호하며, 이는 goto와 매우 유사하기 때문에 하위 프로그램에서 하위 프로그램의 임의 위치에 입력할 수 있는 경우는 매우 드물다.

스테이트 머신

일부 프로그램, 특히 파서와 통신 프로토콜은 기본 구조로 쉽게 축소되지 않는 방식으로 서로 이어지는 많은 상태를 가지고 있으며, 일부 프로그래머는 새로운 상태로의 점프와 함께 상태 변화를 구현합니다.이러한 유형의 상태 스위칭은 Linux [citation needed]커널에서 자주 사용됩니다.

그러나 각 상태 변경을 별도의 하위 프로그램으로 만들고 활성 상태를 나타내는 변수를 사용하여 이러한 시스템을 구성할 수 있습니다(트램펄린 참조).또는 트램폴린이 없는 코루틴을 통해 구현할 수 있습니다.

「 」를 참조해 주세요.

레퍼런스

인용문

  1. ^ Clark, Leslie B. Wilson, Robert G.; Robert, Clark (2000). Comparative programming languages (3rd ed.). Harlow, England: Addison-Wesley. p. 20. ISBN 9780201710120. Archived from the original on 26 November 2015. Retrieved 25 November 2015.
  2. ^ Böhm & Jacopini 1966.
  3. ^ Dijkstra 1968, 페이지 147, "Go to Statement의 제한 없는 사용은 즉각적인 결과로 프로세스 진행을 기술할 의미 있는 좌표 집합을 찾는 것이 매우 어려워집니다. ...지금 상태 그대로의 진술은 너무 원시적이고, 자신의 프로그램을 망치기엔 너무 많은 초대입니다."
  4. ^ 다이크스트라 1968년
  5. ^ Plauger, P. J. (February 12, 1993). Programming on Purpose, Essays on Software Design (1st ed.). Prentice-Hall. p. 25. ISBN 978-0-13-721374-0.
  6. ^ DLS • Donald Knuth • All Questions Answered. YouTube. University of Waterloo. 15 Nov 2018. 48 minutes in. Retrieved 24 July 2022.
  7. ^ Donald E. Knuth (December 1974). "Structured programming with go to statements" (PDF). Computing Surveys. 6 (4): 261–301. doi:10.1145/356635.356640. S2CID 207630080. Archived from the original (PDF) on 2013-10-23.
  8. ^ Frank Rubin (March 1987). ""GOTO Considered Harmful" Considered Harmful" (PDF). Communications of the ACM. 30 (3): 195–196. doi:10.1145/214748.315722. S2CID 6853038. Archived from the original (PDF) on 2009-03-20.
  9. ^ Elder, Matt; Jackson, Steve; Liblit, Ben (October 2008). Code Sandwiches (PDF) (Technical report). University of Wisconsin–Madison. 1647.
  10. ^ Jay Fields; Shane Harvie; Martin Fowler; Kent Beck (2009). Refactoring: Ruby Edition. Pearson Education. pp. 274–279. ISBN 978-0-321-60350-0.
  11. ^ Herb Sutter; Andrei Alexandrescu (2004). C++ Coding Standards: 101 Rules, Guidelines, and Best Practices. Pearson Education. ISBN 978-0-13-265442-5. Example 4: Single entry, single exit ("SESE"). Historically, some coding standards have required that each function have exactly one exit, meaning one return statement. Such a requirement is obsolete in languages that support exceptions and destructors, where functions typically have numerous implicit exits.
  12. ^ 와트 & 핀들레이 2004, 페이지 215–221.
  13. ^ Bertrand Meyer (2009). Touch of Class: Learning to Program Well with Objects and Contracts. Springer Science & Business Media. p. 189. ISBN 978-3-540-92144-8.
  14. ^ "Single-Entry, Single-Exit, Should It Still be Applicable in Object-oriented Languages?". Peter Ritchie's MVP Blog. Archived from the original on 2012-11-14. Retrieved 2014-07-15.
  15. ^ 와트 & 핀들레이 2004, 페이지 221–222.
  16. ^ Kenneth C. Louden; Kenneth A. Lambert (2011). Programming Languages: Principles and Practices (3rd ed.). Cengage Learning. p. 423. ISBN 978-1-111-52941-3.
  17. ^ Arvind Kumar Bansal (2013). Introduction to Programming Languages. CRC Press. p. 135. ISBN 978-1-4665-6514-2.
  18. ^ Weimer, W. & Necula, G.C. (2008). "Exceptional Situations and Program Reliability" (PDF). ACM Transactions on Programming Languages and Systems. 30 (2). 8:27. doi:10.1145/1330017.1330019. S2CID 3136431. Archived from the original (PDF) on 2015-09-23.
  19. ^ Rohit Chandra (2001). Parallel Programming in OpenMP. Morgan Kaufmann. p. 45. ISBN 978-1-55860-671-5.

원천

외부 링크

Wikibook 컴퓨터 프로그래밍에는 다음 항목에 대한 페이지가 있습니다.
  • BPStrackt - 동시 시스템(프로그램, 프로세스 모델)을 구조화하기 위한 도구
  • J. Darlinton; M. Ghanem; H. W. To (1993), "Structured Parallel Programming", In Programming Models for Massively Parallel Computers. IEEE Computer Society Press. 1993: 160–169, CiteSeerX 10.1.1.37.4610