Copyright IBM Corp. 1987, 2005. All Rights Reserved.

"Rational" 및 Rational의 제품은 Rational Software Corporation의 상표입니다. 기타 회사 및 기타 회사의 제품을 나타내는 표장은 해당 회사가 소유하는 상표이며 참고용으로만 제공됩니다.

목차

이 문서 정보

소개

기본 원칙
가정
가이드라인 분류
기본 가이드라인

코드 레이아웃

일반
대소문자 지정
들여쓰기
행 길이 및 행 바꾸기
맞추기

주석

일반
주석 사용 가이드라인

이름 지정 규칙

일반
패키지
유형
예외
서브프로그램
오브젝트 및 서브프로그램(또는 항목) 매개변수
일반 유닛
서브시스템에 대한 이름 지정 전략

유형, 오브젝트 및 프로그램 유닛 선언

열거 유형
숫자 유형
실제 유형
레코드 유형
액세스 유형
private 유형
파생 유형
오브젝트 선언
서브프로그램 및 일반 유닛

표현식 및 명령문

표현식
명령문
코딩 힌트

가시성 문제

오버로드 및 동형 이의어
컨텍스트 절
이름 바꾸기
use 절에 대한 참조사항

프로그램 구조 및 컴파일 문제

패키지 분할
선언 파트 구조
컨텍스트 절
정제 순서

동시성

오류 처리 및 예외

하위 레벨 프로그래밍

표시 절 및 속성
Unchecked_Conversion

요약

참조

용어집


1장

이 문서 정보

이 문서 Rational Unified Process - Ada 프로그래밍 가이드라인은 사용자 조직에 맞는 코딩 표준을 생성하는 데 사용할 수 있는 템플리트로서, Ada 프로그램의 올바른 작성 방법을 지정합니다. Ada를 구현 언어로 사용하거나 인터페이스 또는 데이터 구조를 지정하기 위한 디자인 언어로 사용하는 모든 응용프로그램 소프트웨어 디자이너와 개발자가 이 문서의 사용자입니다.

이 문서에서 설명하는 규칙은 대부분의 코딩 측면을 대해 다룹니다. 일반 규칙은 프로그램 레이아웃, 이름 지정 규칙 및 주석 사용에 적용됩니다. 특정 규칙은 선택한 Ada 기능에 적용되며, 금지 구조, 권장 사용법 패턴 및 프로그램 품질을 강화하기 위한 일반 힌트를 지정합니다.

프로젝트 디자인 가이드라인과 현재 프로그래밍 가이드라인 간에는 의도적으로 중복되는 부분이 포함됩니다. 특히 이름 지정 규칙 영역에서 많은 코딩 규칙이 소프트웨어 디자인에 대한 객체 지향적인 접근 방식을 적극 지원하고 강화하기 위해 채택되었습니다.

가이드라인은 원래 Ada 83용으로 작성되었습니다. 가이드라인에는 Ada 95와의 호환성 규칙이 포함되지만, 개정된 언어 표준에서 도입되는 새 언어 기능(예: 태그 유형, 하위 유닛 또는 10진 유형)의 사용을 위한 특정 가이드라인은 없습니다.

문서 구조는 Ada Reference Manual [ISO 8052]의 구조를 따릅니다.

2장 소개에서는 가이드라인의 기본 원칙에 대해 설명하고 가이드라인 분류를 제공합니다.

3장 코드 레이아웃은 프로그램 텍스트의 일반 시각적 구조에 대해 설명합니다.

4장 주석은 주석을 사용하여 유용하고 유지보수 가능하며 구조화된 방식으로 코드를 문서화하는 방법에 대한 지침을 제공합니다.

5장 이름 지정 규칙은 이름 지정 언어 엔티티에 대한 일반 규칙과 예제를 제공합니다. 이 장은 특정 프로젝트 또는 조직의 요구에 맞게 조정되어야 합니다.

6장 선언과 7장 표현식 및 명령문은 각 언어 구조 유형에 대한 자세한 정보를 제공합니다.

8장 가시성 문제와 9장 프로그램 구조 및 컴파일 문제는 프로그램의 글로벌 구조 및 구성에 대한 지침을 제공합니다.

10장 동시성은 언어의 타스크 지정 및 시간 관련 기능 사용과 관련된 특수 주제에 대해 설명합니다.

11장 오류 처리 및 예외는 체계적이고 간단한 방식으로 오류를 처리하기 위해 예외를 사용하거나 사용하지 않는 방법에 대한 지침을 제공합니다.

12장 하위 레벨 프로그래밍은 표시 절 문제에 대해 설명합니다.

13장 요약은 가장 중요한 가이드라인에 대해 요약 설명합니다.

이 문서는 Ada Guidelines: Recommendations for Designers and programmers, Application Note #15, Rational, Santa Clara, CA., 1990을 대체합니다.


2장

소개

기본 원칙

Ada는 신뢰할 수 있고 재사용 가능하며 이식 가능한 고품질 소프트웨어 개발을 지원하도록 디자인되었습니다[ISO 87, sect. 1.3]. 그러나 프로그래밍 언어만으로 이러한 목적을 달성할 수는 없습니다. 올바른 원칙이 적용되는 프로세스의 일부로 프로그래밍을 수행해야 합니다.

이 문서에서 제공하는 대부분의 가이드라인의 목적은 명확하고 쉽게 이해할 수 있는 Ada 소스 코드를 작성하는 것으로서, 이를 통해 프로그램의 신뢰성 및 유지보수성을 확보할 수 있습니다. 명확하고 쉽게 이해할 수 있는 코드란 다음과 같은 세 가지 간단한 기본 원칙으로 규정할 수 있습니다.

균일성(Minimal Surprise)

소스 코드는 쓰기보다 읽게 되며, 특히 세부화 작업이 수행됩니다. 이상적으로, 코드는 수행하는 내용을 영어로 설명하듯이 읽을 수 있되 실행 가능하다는 이점이 있을 뿐이라고 보는 것이 가장 좋습니다. 프로그램은 컴퓨터보다는 사람을 위해 작성되는 것입니다. 코드 읽기는 복잡한 정신적 프로세스이지만 균일성(Minimal Surprise) 원칙을 유지함으로써 쉬운 작업이 될 수도 있습니다. 전체 프로젝트에서 통일된 스타일을 유지하려면 소프트웨어 개발자 팀이 프로그래밍 표준에 동의해야 하지만, 이를 일종의 처벌이나 창의성과 생산성에 대한 장애물로 인식해서는 안됩니다.

단일 유지보수 지점

이 안내서의 기반이 되는 또 다른 중요 원칙은 단일 유지보수 지점입니다. 가능한 경우 디자인 결정은 Ada 소스 내 한 지점에서만 표현되어야 하며 대부분의 해당 결과는 이 지점에서 프로그래밍 방식으로 파생되어야 합니다. 이 원칙을 위반하는 경우 유지보수성 및 신뢰성은 물론 이해용이성에도 나쁜 영향을 주게 됩니다.

최소 혼잡

마지막은 읽기 쉽게 하는 중요한 요인으로 최소 혼잡 원칙을 적용해야 합니다. 즉, 막대, 상자 및 정보 내용이 거의 없거나 소프트웨어의 목적을 이해하는 데 불필요한 정보를 제공하는 텍스트와 같은 시각적 "혼잡"으로 소스 코드를 어지럽게 만들어서는 안됩니다.

이식성 및 재사용 가능성 또한 가이드라인이 추구하는 목표입니다. 코드는 다른 대상 컴퓨터의 여러 가지 다양한 컴파일러와 궁극적으로는 Ada의 상위 버전인 "Ada 95"로 포팅되어야 합니다[PLO92, TAY92].

가정

이 가이드라인에서는 다음 몇 가지를 가정합니다.

사용자가 Ada 언어에 대해 알고 있습니다.

고급 Ada 기능은 필요할 때마다 사용하는 것이 좋으며, 프로그래머에게 친숙하지 않다고 해서 사용하지 않아서는 안됩니다. 이를 사용해야만 프로젝트에 Ada 사용의 이점을 이용할 수 있습니다. Ada는 Pascal 또는 FORTRAN과 같이 사용해서는 안됩니다. 코드를 주석에 풀어 쓰는 것은 바람직하지 않습니다. 그 대신 가능한 경우 Ada를 주석 대신 사용해야 합니다.

사용자가 영어를 이해합니다.

많은 이름 지정 규칙은 어휘 및 구문 면에서 영어를 기반으로 합니다. 또한 Ada 키워드도 일반 영어 단어이며 이러한 키워드에 다른 언어가 혼합되면 읽기 어려워집니다.

use 절을 사용하면 안됩니다.

이름 지정 규칙 및 기타 다른 규칙에서는 "use" 절을 사용하지 않는 것으로 가정합니다.

대규모 프로젝트를 다룹니다.

많은 규칙은 대규모 Ada 시스템에서 가장 큰 가치를 제공하지만, 프로젝트 또는 회사 레벨에서의 실습 및 통일만을 원하는 경우 소규모 시스템에서도 사용할 수 있습니다.

Rational Environment에서 소스 코드를 개발합니다.

Rational Environment를 사용함으로써, Ada 편집기 및 포맷터로 코드 레이아웃, 닫기 구조의 ID 등과 같은 문제를 다루게 됩니다. 그러나 이 문서에 포함된 레이아웃 권장사항은 모든 개발 플랫폼에 적용할 수 있습니다.

코딩은 객체 지향 디자인을 따릅니다.

많은 규칙은 Ada 기능 및 특정 이름 지정 규칙에 대한 객체 지향(OO) 개념의 시스템 맵핑을 지원합니다.

가이드라인 분류

모든 가이드라인의 중요성이 같지는 않으며 중요성에 따라 다음과 같이 분류됩니다.

힌트:검지 아이콘

이 가이드라인은 간단한 조언이므로 해당 내용을 따르지 않아도 아무런 문제가 없습니다. 즉, 원하는 대로 선택하거나 거부할 수 있습니다. 힌트는 이 문서에서 위의 기호로 표시됩니다.

권장사항:오케이 표시 아이콘

이 가이드라인은 일반적으로 보다 기술적인 배경을 기반으로 합니다. 즉, 이식성 또는 재사용 가능성과 일부 구현에서는 성능에도 영향을 줄 수 있습니다. 권장사항은 특별한 이유가 없는 한 수행해야 합니다. 이 문서에는 몇 가지 예외도 언급되어 있습니다. 권장사항은 이 문서에서 위의 기호로 표시됩니다.

제한사항:손 모양 주의 아이콘

문제가 있는 기능은 사용하지 않는 것이 좋지만 완전히 금지되지는 않습니다. 이러한 기능의 사용은 프로젝트 레벨에서 결정하며 해당 결정은 시각적으로 명확하게 표시되어야 합니다. 제한사항은 이 문서에서 위의 기호로 표시됩니다.

요구사항:검지 아이콘

위반하는 경우 코드가 잘못되거나 신뢰할 수 없거나 이식할 수 없게 됩니다. 요구사항은 반드시 준수해야 합니다. 요구사항은 이 문서에서 위의 검지 모양 아이콘으로 표시됩니다.

Rational Design Facility는 제한된 기능 사용을 표시하고 필수 규칙 및 대부분의 권장사항을 강제 실행하는 데 사용됩니다.

다른 많은 Ada 코딩 표준과 달리, 이 가이드라인에서 완전히 금지되는 Ada 기능은 거의 없습니다. 즉, 좋은 소프트웨어를 만들기 위해서는 다음을 따라야 합니다.

기본 가이드라인

검지 아이콘상식을 따르십시오.

규칙 또는 가이드라인이 없거나 규칙이 명확히 적용되지 않거나 어떤 방법으로도 실패하는 경우 상식선에서 기본 원칙을 확인하십시오. 이 규칙은 다른 모든 규칙에 우선합니다. 즉, 가장 필요한 요소는 상식입니다.


3장

코드 레이아웃

일반

프로그램 유닛의 레이아웃은 Rational Environment Formatter에 의해 완전 제어되므로 프로그래머는 주석 및 공백을 제외한 프로그램 레이아웃에 대해 그다지 걱정하지 않아도 됩니다. 이 도구에서 채택한 포맷팅 규칙은 Reference Manual for the Ada Programming Language [ISO87]의 부록 E에서 설명합니다. 특히 여기에서는 구조적 구조를 시작 및 종료하는 키워드를 수직으로 맞추도록 제안합니다. 또한 구조 ID가 구조 끝에서 체계적으로 반복되어야 합니다.

포맷터의 정확한 동작은 일련의 라이브러리 스위치에 의해 제어되며 이 스위치는 공통 모델 환경을 기반으로 프로젝트 전체에서 통일된 값 세트를 받습니다. 해당 스위치는 권장되는 모델 환경에 대한 현재 값과 함께 아래에 나열됩니다.

대소문자 지정

Format . Id_Case : Letter_Case := Capitalized

ID의 대소문자를 Ada 유닛으로 지정합니다. 맨 처음 문자와 밑줄 다음의 각 첫 번째 문자는 대문자입니다. 대문자로 시작하는 양식은 최신 화면 및 레이저 프린터 글꼴을 사용했을 때 사용자가 가장 쉽게 읽을 수 있는 양식입니다.

Format . Keyword_Case : Letter_Case := Lower

Ada 키워드의 대소문자를 지정하여 ID와 구분할 수 있습니다.

Format . Number_Case : Letter_Case := Upper

부동 소수점 리터럴과 기본 리터럴의 기본 숫자("A" - "F")에서 문자 "E"의 대소문자를 지정합니다.

들여쓰기

Ada 유닛은 Ada Reference Manual [ISO87]의 부록 E에 표현되는 일반 규칙에 따라 형식화됩니다. 즉, 구조적 구조를 시작 및 종료하는 키워드가 맞춰집니다(예: "loop"와 "end loop", "record"와 "end record"). 구조적 구조 내부에 있는 요소는 오른쪽으로 들여쓰기합니다.

Format . Major_Indentation : Indent_Range := 3

"if" 문, "case" 문 및 "loop" 문과 같은 체계적인 기본 구조를 포맷터가 들여쓰기하는 열 수를 지정합니다.

Format . Minor_Indentation : Indent_Range := 2

레코드 선언, 가변 레코드 선언, 유형 선언, 예외 핸들러, 대안, case 문 및 이름이 지정되고 레이블 표시가 된 명령문과 같은 보조 구조를 포맷터가 들여쓰기하는 열 수를 지정합니다.

행 길이 및 행 바꾸기

Format . Line_Length : Line_Range := 80

포맷터가 줄 바꾸기를 수행하기 전에 Ada 유닛으로 행을 인쇄하기 위해 사용하는 열 수를 지정합니다. 이 값을 지정하면 터미널과 같이 종래의 VT100으로 형식화된 유닛을 표시할 수 있습니다.

Format . Statement_Indentation : Indent_Range := 3

명령문이 Line_Length보다 길어서 분할해야 하는 경우 포맷터가 해당 명령문의 두 번째 및 후속 행을 들여쓰기하는 열 수를 지정합니다. 포맷터는 들여쓰기한 코드를 맞출 수 있는 렉시칼 구조가 없는 경우에만 Statement_Indentation 열 수를 들여쓰기합니다.

Format . Statement_Length : Line_Range := 35

명령문을 표시하기 위해 각 행에서 예약된 열 수를 지정합니다. 현재 들여쓰기 레벨에서 한 행에 Statement_Length 열 수보다 적은 열을 허용하는 경우 포맷터가 Wrap_Indentation 열을 새 들여쓰기 레벨로 다시 시작합니다. 이 방법을 사용하면 깊게 중첩된 명령문이 오른쪽 여백을 넘어 인쇄되지 않습니다.

Format . Wrap_Indentation : Line_Range := 16

현재 들여쓰기 레벨에서 Statement_Length를 허용하지 않는 경우 포맷터가 다른 들여쓰기 레벨을 시작할 열을 지정합니다. 이 방법을 사용하면 깊게 중첩된 명령문이 오른쪽 여백을 넘어 인쇄되지 않습니다.

맞추기

Format . Consistent_Breaking : Integer := 1

서브프로그램 정규 파트 또는 유형 선언의 판별식으로서 표시되는 양식(xxx:aaa; yyy:bbb)의 목록 포맷팅을 제어합니다. 또한 서브프로그램 호출 및 집계에 표시되는 양식(xxx=>aaa, yyy=>bbb)의 목록 포맷팅을 제어합니다. 이 옵션은 0이 아니므로(true), 목록이 한 행을 넘는 경우 목록의 모든 요소가 새 행에서 시작됩니다.

Format . Alignment_Threshold : Line_Range := 20

포맷터가 연속 명령문에서 렉시칼 구조(예: 콜론, 지정 및 이름 지정 표기의 화살표)를 맞추기 위해 삽입할 수 있는 공백 수를 지정합니다. 구조를 맞추는데 이 수보다 많은 공백이 필요한 경우, 해당 구조의 왼쪽 맞추기가 취소됩니다.

검지 아이콘특정 레이아웃을 강제 실행하기 위해 프로그래머는 행 끝을 삽입하거나, <space> <space> <carriage-return>을 입력하여 포맷터로 제거되지 않는 행 바꾸기를 삽입할 수 있습니다.

오케이 표시 아이콘이 기법을 사용하여 코드를 읽기 쉽게 작성하고 유지보수성을 향상시키려면 목록의 항목이 네 개 이상이거나 한 행을 초과하는 경우 Ada 요소 목록을 행당 하나의 요소만 포함하도록 분할해야 합니다. 특히 이 사항은 다음 Ada 구조에 적용됩니다(Ada Reference Manual [ISO87]의 부록 E에 정의).

인수 연관

pragma Suppress (Range_Check,
                 On => This_Type,
                 On => That_Type,                 On => That_Other_Type);      

ID 목록, 컴포넌트 목록

Next_Position,
Previous_Position,
Current_Position : Position;
type Some_Record is 
    record
        A_Component,
        B_Component,
        C_Component : Component_Type;
    end record;      

열거 유형 정의

type Navaid is 
       (Vor, 
        Vor_Dme, 
        Dme, 
        Tacan, 
        VorTac, 
        NDB);      

판별 제한조건

subtype Constrained is Element 
        (Name_Length    => Name'Length,
         Valid          => True,
         Operation      => Skip);      

명령문 시퀀스(포맷터가 수행)

정규 파트, 일반 정규 파트, 실제 매개변수 파트, 일반 실제 매개변수 파트

procedure Just_Do_It (This     : in Some_Type;
                      For_That : in Some Other_Type;
                      Status   : out Status_Type);
Just_Do_It (This     => This_Value;
            For_That => That_Value;
            Status   => The_Status);      

4장

주석

일반

일반적으로 알려져 있는 것과 달리 좋은 프로그램이란 주석 가 아닌 그 품질로 결정됩니다.

주석은 Ada 코드를 부연 설명하는 것이 아닌 보완하기 위해 사용해야 합니다. Ada는 그 자체가 매우 읽기 쉬운 프로그래밍 언어이지만 올바른 이름 지정 규칙에 의한 지원을 통해 보다 읽기 쉬워질 수 있습니다. 주석은 명확하지 않은 내용을 설명하여 Ada 코드를 보완하되 Ada 구문 또는 시맨틱을 중복해서는 안됩니다. 주석은 사용자가 배경 개념, 종속성 및 특히 복잡한 데이터 인코딩 또는 알고리즘을 이해하는 데 도움을 줘야 합니다. 주석은 코딩 또는 디자인 표준을 따르지 않은 부분, 제한된 기능의 사용 및 특별한 "요령"을 강조해야 합니다. 각 주요 Ada 구조(예: 서브프로그램 및 패키지)에 대해 체계적으로 표시되는 주석 프레임 또는 양식은 통일성이라는 이점을 제공하며 프로그래머에게 코드를 문서화하도록 상기시키지만 부연 설명 형태가 될 수 있으므로 주의해야 합니다. 프로그래머는 각 주석에 대해 "이 주석으로 어떤 가치가 추가되는가?"라는 질문에 대답할 수 있어야 합니다.

잘못된 주석은 주석을 사용하지 않는 것보다 나쁜 결과를 가져옵니다. Rational Design Facility에서처럼 정규 ADL(Ada Design Language) 또는 PDL(Program Design Language)과 관련되지 않은 주석은 컴파일러로 확인이 되지 않습니다. 따라서 단일 유지보수 지점 원칙에 따라, 몇 가지 선언이 더 추가되는 한이 있더라도 디자인 결정은 주석이 아닌 Ada로 표현해야 합니다.

예를 들어, 다음 선언을 고려할 수 있습니다(올바른 예는 아님).

------------------------------------------------------------
-- procedure Create
------------------------------------------------------------
--
   procedure Create
              (The_Subscriber: in out Subscriber.Handle;
               With_Name     : in out Subscriber.Name);
--
-- Purpose: This procedure creates a subscriber with a given
-- name. 
--
-- Parameters: 
-     The_Subscriber    :mode in out, type Subscriber.Handle
-               It is the handle to the created subscriber
-     With_Name         :mode in, type Subscriber.Name
-               The name of the subscriber to be created.
-               The syntax of the name is
--                 <letter> { <letter> | <digit> }
-- Exceptions:
--    Subscriber.Collection_Overflow when there is no more
--    space to create a new subscriber
--    Subscriber.Invalid_Name when the name is blank or
--    malformed
--
-------------------------------------------- end Create ----      

이 예제를 통해 몇 가지를 생각해볼 수 있습니다.

- 프로시저 작성: 이름을 변경해야 하는 경우, 여러 곳을 변경해야 합니다. 그러나 컴파일러로 일관적인 주석 변경은 수행되지 않습니다.
- 매개변수, 해당 이름, 모드 및 유형을 주석에서 반복하지 않아도 됩니다.
- 이 예제에 포함된 각 Ada 엔티티에 대해 올바른 이름이 선택되어 목적 및 매개변수 설명이 불필요하게 됩니다. 이는 위에 표시된 단순 서브프로그램에도 해당됩니다. 보다 복잡한 서브프로그램의 경우에는 목적 및 매개변수에 대한 설명이 필요합니다.

이 경우 다음과 같이 보다 정확하고 유용한 버전을 작성해야 합니다.

procedure Create (The_Subscriber : in out Subscriber.Handle;
                  With_Name      : in    Subscriber.Name);--
--Raises Subscriber.Collection_Overflow.
--Raises Subscriber.Invalid_Name when the name is 
--blank or malformed (see syntax description 
--attached to  declaration of type Subscriber.Name).      

주석 사용 가이드라인

오케이 표시 아이콘주석은 다음과 같이 연관된 코드 근처에 동일한 들여쓰기 레벨로 배치되어야 하며, 공백 주석 행을 사용하여 주석 블록을 Ada 구조에 시각적으로 추가하면서 코드에 첨부되어야 합니다.

procedure First_One;
--
-- This comment relates to First_One.
-- But this comment is for Second_One.
-- 
procedure Second_One (Times : Natural);      

오케이 표시 아이콘소스 코드의 관련 블록(주석 및 코드)을 분리하려면 긴 주석 행 대신 빈 행을 사용하십시오.

오케이 표시 아이콘단락을 분리하려면 다음과 같이 단일 주석 블록 내에서 빈 행 대신 빈 주석을 사용하십시오.

-- Some explanation here that needs to be continued in a
-- subsequent paragraph.
--
-- The empty comment line above makes it clear that we 
-- are dealing with a single comment block.      

오케이 표시 아이콘주석은 관련 Ada 구조의 위 또는 아래에 배치할 수 있지만, 섹션 제목 또는 여러 Ada 구조에 적용되는 주요 정보와 같은 주석은 구조 에 배치하십시오. 비고 또는 추가 정보와 같은 주석은 적용되는 Ada 구조 아래에 배치하십시오.

오케이 표시 아이콘전체 페이지 너비를 사용하여 Ada 구조 시작 위치에서 주석을 그룹화하십시오. Ada 구조와 동일한 행에 주석을 배치하지 마십시오. 주석을 이러한 위치에 배치하면 잘못 맞춰질 수 있습니다. 그러나 열거 유형 리터럴과 같이 긴 선언에서 각 요소를 설명할 때는 이러한 주석을 사용할 수 있습니다.

오케이 표시 아이콘섹션 제목에는 표준 주석 블록에 작은 계층 구조를 사용하되, 대규모 Ada 유닛(>200개 선언 또는 명령문)에서만 사용하십시오.

--===========================================================
--
--               MAJOR TITLE HERE
--
--===========================================================


-------------------------------------------------------------
--               Minor Title Here
-------------------------------------------------------------


--             --------------------
--               Subsection Header
--             --------------------      

제목 주석 아래보다는 위에 빈 행을 더 추가하십시오(예: 앞에 두 행, 뒤에 한 행). 이렇게 하면 제목과 그 다음 텍스트가 시각적으로 잘 연결되어 보입니다.

오케이 표시 아이콘작성자, 전화번호, 작성 및 수정 날짜 및 유닛 위치(또는 파일 이름)와 같은 정보를 포함하는 헤더를 사용하지 마십시오. 이러한 정보는 금방 쓸모없는 정보가 되기 마련입니다. 특히 Rational Environment를 사용하는 경우 소유권 및 저작권 정보는 유닛 끝에 배치하십시오. 예를 들어, Rational Environment에서 [정의]를 눌러 패키지 스펙의 소스에 액세스하는 경우, 사용자는 프로그램 이해에 유용하지 않은 텍스트 및/또는 저작권 사항과 같이 프로그램 정보가 전혀 포함되지 않은 텍스트를 2 - 3페이지 넘겨봐야 할 수 있습니다. 시각적으로 지저분하고 일관되게 유지하기 어려운 세로줄, 닫힌 프레임 또는 상자를 사용하지 마십시오. 유닛 히스토리를 보관하려면 Rational CMVC 노트(또는 다른 양식의 소프트웨어 개발 파일)를 사용하십시오.

오케이 표시 아이콘다른 부분에서 일반적으로 표시되는 정보는 중복하는 대신 해당 정보에 대한 포인터를 제공하십시오.

오케이 표시 아이콘가능한 경우 주석보다는 Ada를 사용하십시오. Ada를 사용함으로써 보다 좋은 이름, 임시 변수, 자격, 이름 바꾸기, 하위 유형, 정적 표현식 및 속성을 사용할 수 있습니다. 올바른 컴파일러를 사용하는 경우 이들 모두 생성된 코드에 영향을 주지 않습니다. 또한 짧은 인라인 술부 함수를 사용하여 해당 코드를 매개변수가 없는 여러 프로시저로 분할할 수 있습니다. 각 프로시저의 이름은 코드의 여러 섹션에 대한 해당 제목을 제공합니다.

예제:

Replace:

exit when Su.Locate (Ch, Str) /= 0; 
-- Exit search loop when found it.      

Search_Loop : loop

Found_It := Su.Locate (Ch, Str) /= 0;

exit Search_Loop when Found_It

end Search_Loop;

Replace:

if Value < 'A' or else Value > 'Z' then 
-- If not in uppercase letters.      

subtype Uppercase_Letters is Character range 'A' .. 'Z';
if Value not in Uppercase_Letters then ...      

Replace:

X := Green;         -- This is the Green from 
                    -- Status, not from Color.
raise Fatal_Error;  -- From package Outer_Scope.
delay 384.0;        -- Equal to 6 minutes and 24 
                    -- seconds.      

The_Status := Green;      

X := Status'(Green);
raise Outer_Scope.Fatal_Error;
delay 6.0 * Minute + 24.0 * Second;      

Replace:

if Is_Valid (The_Table (Index).Descriptor(Rank).all) then
-- This is the current value for the iteration; if it is 
-- valid we append to the list it contains.
   Append (Item,           To_List => The_Table (Index).Descriptor(Rank).Ptr);|      

declare
    Current_Rank : Lists.List renames The_Table 
                    (Index).Descriptor (Rank);
begin
    if Is_Valid (Current_Rank.all) then
        Append (Item, To_List => Current_Rank.Ptr);
    end if;
end;      

오케이 표시 아이콘주석의 스타일, 구문 및 맞춤법에 유의하십시오. 약어 또는 암호 형태는 사용하지 마십시오. 맞춤법 검사기를 사용하십시오 (Rational Environment에서 Speller.Check_Image 호출).

검지 아이콘강조 문자 또는 영어 이외의 문자를 사용하지 마십시오. 주석에서는 Ada Issue AI-339에 따라 일부 개발 시스템 및 일부 Ada 컴파일러에서만 영어 이외의 문자가 지원됩니다. 그러나 이 지원은 이식성이 없으므로 다른 시스템에서는 사용할 수 없습니다.

오케이 표시 아이콘서브프로그램의 경우 최소 문서화 요구사항은 다음과 같습니다.

오케이 표시 아이콘유형 및 오브젝트의 경우, Ada로 표현할 수 없는 불변 또는 추가 제한조건을 문서화하십시오.

검지 아이콘주석 내용을 반복하지 마십시오. 예를 들어, 목적 섹션은 "해당 방법"이 아닌 "해당 기능"에 대한 간략한 설명이어야 합니다. 또한 개요는 해당 디자인에 대한 간략한 설명이어야 합니다. 이러한 설명은 사용된 알고리즘이 아닌 패키지 사용 방법에 대해 설명해야 합니다.

Data_Structure 및 알고리즘 섹션에는 올바른 패키지 사용을 위해 기본 구현 전략을 이해하는 데 필요한 정보가 포함되어야 하며 모든 구현 세부사항 또는 이 패키지의 올바른 사용과 관련되지 않은 정보는 제공하지 않아도 됩니다.


5장

이름 지정 규칙

일반

Ada 엔티티(프로그램 유닛, 유형, 하위 유형, 오브젝트, 리터럴 및 예외)를 지정하는 올바른 이름을 선택하는 것은 모든 소프트웨어 응용프로그램에 적용되는 가장 민감한 문제 중 하나입니다. 그러나 중간 또는 대규모 응용프로그램의 경우 이름 충돌이라는 또 다른 문제점이 있습니다. 즉 실제 생활에서의 동일한 개념에 대해 구별되면서도 유사한 개념을 지정하는(또는 유형, 하위 유형, 오브젝트, 매개변수의 이름을 지정하는) 동의어를 찾아야 하는 어려움이 있습니다. 여기에서 "use" 절을 사용하지 않는 규칙(또는 극도로 제한된 조건에서만 사용)이 적용됩니다. 많은 경우, 이를 통해 이름 길이가 짧아지고 혼동 없이 동일한 설명 단어를 재사용할 수 있습니다.

확인 아이콘명확하고 읽기 쉬우며 의미있는 이름을 선택하십시오.

다른 많은 프로그래밍 언어와 달리, Ada는 ID 길이를 6, 8 또는 15자로 제한하지 않습니다. 입력 속도가 늦다고 해서 짧은 이름을 사용하는 것은 좋지 않습니다. 한 글자로 된 ID를 사용하는 것은 일반적으로 잘못된 선택이나 작성자의 게으름을 나타낼 뿐입니다. 여기서 자연 대수의 기반으로 사용되는 E, Pi, 또는 이미 잘 알려져 있는 몇 가지 경우는 제외됩니다.

오케이 표시 아이콘다음과 같이 여러 단어로 구성되는 이름은 밑줄로 분리하십시오.

IsNameValid보다는 Is_Name_Valid를 사용하십시오.

오케이 표시 아이콘약어보다는 완전한 이름을 사용하십시오.

오케이 표시 아이콘프로젝트에서 승인된 약어만 사용하십시오.

약어를 사용하는 경우, 응용프로그램 분야에서 매우 일반적인 약어(예: FFT- Fast Fourier Transform)이거나 승인된 프로젝트 레벨의 약어 목록에서 가져온 것이어야 합니다. 그렇지 않은 경우 비슷하지만 틀린 약어가 사용되어 혼란을 야기시키고 나중에 오류를 발생시킬 수 있습니다(예: Track_Identification의 약어로 Tr_Id, Trck_Id, Tr_Iden, Trid, Tid, Tr_Ident 등을 사용).

오케이 표시 아이콘Ada 구조의 카테고리를 나타내는 접미부는 반드시 필요한 경우에만 사용하십시오. 이러한 접미부는 읽기 어렵게 만듭니다.

Ada 엔티티 카테고리별 접미부(예: 패키지의 _Package, 예외의 _Error, 유형의 _Type, 서브프로그램 매개변수의 _Param)는 일반적으로 코드를 읽고 이해하는 프로세스에 그다지 효과적이지 않습니다. 오히려 _Array, _Record 및 _Function과 같은 접미부는 더 나쁜 결과를 가져옵니다. Ada 컴파일러와 사용자는 모두 컨텍스트를 통해 예외와 서브프로그램을 구분할 수 있습니다. 즉, raise 문 또는 예외 핸들러에는 당연히 예외 이름만 표시됩니다. 이러한 접미부는 다음과 같이 제한적인 상황에서만 유용합니다.

접미부가 by _Constrained인 일반 정규 유형

접미부가 by _Pointer인 액세스 유형 또는 다른 양식의 간접 참조(by_Handle 또는 _Reference)

_Or_Wait로 잠재적 차단 입력 호출을 숨기는 서브프로그램

오케이 표시 아이콘 사용법 관점에서 올바르게 보이는 이름으로 표현하십시오.

내보낸 엔티티가 사용될 컨텍스트를 고려하여 해당 관점에서 이름을 선택하십시오. 엔티티는 한 번만 선언되지만 여러 번 사용됩니다. 이는 특히 서브프로그램 이름 및 해당 매개변수에 적용됩니다. 이름 지정 연관을 사용하는 결과 호출은 자연어와 최대한 유사해야 합니다. use 절이 없으므로 대부분의 선언 엔티티에 규정된 이름을 강제로 사용하게 됩니다. 일반 정규 매개변수에 대해서는 올바른 절충안이 필요합니다. 이러한 매개변수는 클라이언트측보다는 일반 유닛에서 많이 사용되지만 서브프로그램 정규 매개변수에 대해 클라이언트측에서도 올바르게 표시되어야 합니다.

오케이 표시 아이콘영어 단어를 사용하되 맞춤법에 유의하십시오.

몇 가지 언어(예: 불어와 영어)를 함께 사용하는 경우, 코드를 읽기가 어렵고 경우에 따라 ID 의미가 모호해질 수 있습니다. Ada 키워드가 이미 영어이므로 영어 단어를 사용해야 합니다. Rational Environment의 내장 맞춤법 검사기를 사용하려면 미국식 영어 맞춤법이 선호됩니다.

검지 아이콘Standard 패키지의 엔티티는 절대로 재정의해서는 안됩니다.

Standard 엔티티를 재정의하는 경우 심각한 혼동과 문제가 야기됩니다. 이 규칙은 사전 정의된 다른 라이브러리 단위(달력, 시스템)에도 적용됩니다. 또한 ID Standard에도 적용됩니다.

오케이 표시 아이콘시스템 또는 달력과 같이 사전 정의된 다른 패키지에서 ID를 재정의하지 마십시오.

검지 아이콘 Wide_CharacterWide_String은 Ada 95의 Standard 패키지에서 사용될 예정이므로 ID로 사용하지 마십시오. 또한 컴파일 단위 이름도 Ada로 지정하지 마십시오.

검지 아이콘abstract, aliased,protected, requeue, taggeduntil은 Ada 95에서 키워드로 사용될 예정이므로 ID로 사용하지 마십시오.

다양한 Ada 엔티티에 대해 이름 지정 제안이 뒤따릅니다. 일반적으로 "오브젝트 표시" 스타일의 디자인이 가정됩니다. 자세한 내용은 부록 A를 참조하십시오.

패키지

오케이 표시 아이콘패키지에서 일부 오브젝트 클래스가 소개되는 경우, 일반적으로 단수 형태의 일반 명사인 오브젝트 클래스의 이름을 부여하십시오. 필요한 경우(즉 매개변수 클래스가 정의된 경우) 접미사 _Generic을 사용하십시오. 복수 형태는 오브젝트가 그룹으로 지정되는 경우에만 사용하십시오. 예를 들어, 다음과 같습니다.

package Text is
package Line is
package Mailbox is
package Message is
package Attributes is
package Subscriber is
package List_Generic is      

오케이 표시 아이콘패키지가 인터페이스 또는 기능 그룹을 지정하고 오브젝트와 관련이 없는 경우, 다음과 같이 해당 내용을 이름에 표현하십시오.

package Low_Layer_Interface is
package Math_Definitions is      

오케이 표시 아이콘수평 분할을 사용하여 "논리" 패키지를 여러 패키지로 표현해야 하는 경우, 프로젝트 레벨에서 승인된 목록에서 가져온 접미부를 사용하십시오. 예를 들어, Mailbox 논리 패키지의 경우. 다음과 같이 구현할 수 있습니다.

package Mailbox_Definitions is
package Mailbox_Exceptions is
package Mailbox_Io is
package Mailbox_Utilities is
package Mailbox_Implementation is
package Mailbox_Main is      

이 밖에도 다음과 같은 접미부를 사용할 수 있습니다.

_Test_Support 
_Test_Main 
_Log 
_Hidden_Definitions 
_Maintenance 
_Debug      

유형

오케이 표시 아이콘오브젝트 클래스를 정의하는 패키지에서는 다음을 사용하십시오.

type Object is ...      

 

복사 시맨틱을 의미하는 경우(즉 유형을 인스턴스화할 수 있고 일부 지정 양식을 실행할 수 있는 경우)에 해당됩니다. 클래스 이름은 완전한 양식으로만 사용되므로 ID에서 반복되어서는 안됩니다.

Mailbox.Object
Line.Object      

검지 아이콘공유 시맨틱을 의미하는 경우(즉 액세스 값(또는 다른 특정 양식의 간접 지정)으로 해당 유형이 구현되며, 지정을 수행해도 오브젝트가 복사되지 않음), 이 내용을 다음을 사용하여 표시하십시오.

 

요소는 패키지 이름 접두부만으로는 해당 용도가 명백하지 않거나 모호한 경우 접미부로서 사용됩니다.

검지 아이콘복수 오브젝트를 의미하는 경우, 다음 중 하나를 사용하십시오.

검지 아이콘일부 오브젝트 문자열 지정의 경우, 다음을 사용하십시오.

type Name

오케이 표시 아이콘읽기 쉽게 하기 위해 유형의 규정된 이름을 정의 패키지 전체에서도 사용해야 합니다. 이렇게 하면 Rational Environment에서 서브프로그램 호출에 대해 [전체] 기능을 사용하여 동작을 보다 효과적으로 수행할 수 있습니다.

예를 들어, 다음에서 전체 이름 Subscriber.Object에 유의하십시오.

package Subscriber is
    type Object is private;
    type Handle is access Subscriber.Object;
    subtype Name is String;
    package List is new List_Generic (Subscriber.Handle);
    Master_List : Subscriber.List.Handle;
    procedure Create (The_Handle : out Subscriber.Handle;
                      With_Name  : in  Subscriber.Name);
    procedure Append (The_Subscriber : in     Subscriber.Handle;
                      To_List        : in out Subscriber.List.Handle);
    function Name_Of (The_Subscriber : Subscriber.Handle) return
            Subscriber.Name;
    ...
private
    type Object is
        record
            The_Name : Subscriber.Name (1..20);
                    ...
end Subscriber;    

검지 아이콘다른 경우에서는 유형 이름으로 명사 또는 규정자+명사를 사용하십시오. 유형에는 복수 형태를 사용하고 오브젝트(변수)에는 단수 형태를 사용할 수 있습니다.

type Point is record ...
type Hidden_Attributes is ( ...
type Boxes is array ...    

열거 유형의 경우, Mode, Kind, Code 등을 그 자체로 사용하거나 또는 접미부로 사용하십시오.

배열 유형의 경우, 컴포넌트 유형에 이미 단순한 이름이 사용된 경우 접미부 _Table을 사용할 수 있습니다. _Set 및 _List와 같은 이름 또는 접미부는 배열이 해당 시맨틱을 사용하여 유지보수되는 경우에만 사용하십시오. 해당 수리 개념을 위해 _Vector 및 _Matrix를 남겨 두십시오.

검지 아이콘단일 타스크 오브젝트는 사용하지 않으므로(그 이유는 나중에 설명함) 해당 유형의 오브젝트가 하나인 경우라도 타스크 유형을 사용해야 합니다. 다음은 _Type과 같은 단순한 접미부 전략으로 충분한 경우입니다.

task type Listener_Type is ...
for Listener_Type'Storage_Size use ...
Listener : Listener_Type;    

검지 아이콘마찬가지로, 유형 이름에 명사(또는 명사구)를 사용할 때나 오브젝트 또는 매개변수 이름에 대한 여러 위치에서 충돌이 발생하는 경우, 다음과 같이 해당 명사의 접미부로 _Kind를 사용하고 오브젝트에는 단순 명사를 사용하십시오.

type Status_Kind is (None, Normal, Urgent, Red);
Status : Status_Kind := None;    

검지 아이콘또는 항상 복수 형태인 대상의 경우에는 복수 유형 형태를 사용하십시오.

오케이 표시 아이콘액세스 유형에는 위험이 내재되어 있을 수 있으며 사용자에게 이를 알려야 합니다. 이를 일반적으로 포인터라고 합니다. 이름만 사용하면 모호한 경우 접미부 _pointer를 사용하십시오. _Access를 사용할 수도 있습니다. ;

검지 아이콘다음과 같이 경우에 따라 중첩된 서브패키지를 사용하여 보조 추상을 도입하면 이름 지정 작업이 단순해집니다.

package Subscriber is    ...
    package Status is
        type Kind is (Ok, Deleted, Incomplete, Suspended, 
                      Privileged);
        function Set (The_Status    : Subscriber.Status.Kind;
                      To_Subscriber : Subscriber.Handle);
    end Status;
    ...    

예외

오케이 표시 아이콘예외는 오류 상황을 처리하는 용도로만 사용되어야 하므로 다음과 같이 부정적인 의미를 명확히 전달하는 명사 또는 명사구를 사용하십시오.

Overflow, Threshold_Exceeded, Bad_Initial_Value    

클래스 패키지에 정의되는 경우, 해당 ID에 클래스 이름을 포함할 필요가 없습니다(예: Bad_Initial_Subscriber_Value). 이 예외는 항상 Subscriber.Bad_Initial_Value로 사용되기 때문입니다.

오케이 표시 아이콘특정 정보를 제공하지 않는 Error를 체계적으로 사용하는 대신 Bad, Incomplete, Invalid, Wrong, Missing 또는 Illegal 중 하나를 이름의 일부로 사용하십시오.

Illegal_Data, Incomplete_Data    

서브프로그램

오케이 표시 아이콘프로시저(및 타스크 항목)에는 동사를 사용하십시오. 함수에 대한 오브젝트 클래스의 속성 또는 특성에는 명사를 사용하십시오. 부울(술부)을 리턴하는 함수에는 형용사(또는 과거 분사)를 사용하십시오.

Subscriber.Create
Subscriber.Destroy
Subscriber.List.Append
Subscriber.First_Name          -- Returns a string.
Subscriber.Creation_Date       -- Returns a date.
Subscriber.List.Next
Subscriber.Deleted             -- Returns a Boolean.
Subscriber.Unavailable         -- Returns a Boolean.
Subscriber.Remote    

검지 아이콘술부의 경우, 경우에 따라 명사 앞에 접두부 Is_ 또는 Has_를 추가하는 것이 유용합니다. 이 경우 시제를 정확하고 일관되게 적용해야 합니다.

function Has_First_Name ...
function Is_Administrator ...
function Is_First...
function Was_Deleted ...    

이는 간단한 이름이 이미 유형 이름 또는 열거 리터럴로 사용된 경우에 유용합니다.

술부는 긍정적 양식을 사용하십시오. 즉, "Not_"을 포함하지 마십시오.

일반 오퍼레이션의 경우, 선택한 프로젝트 목록(시스템에 대한 지식이 쌓일수록 커지는 목록)에서 가져온 동사를 일관되게 사용하십시오.

Create
Delete
Destroy
Initialize
Append
Revert
Commit
Show, Display    

검지 아이콘술부 함수 및 부울 매개변수에는 긍정적인 이름을 사용하십시오. 부정적인 이름을 사용하면 이중 부정(예: Not Is_Not_Found)이 생겨 코드를 읽기 어렵게 됩니다.

function Is_Not_Valid (...) return Boolean
procedure Find_Client (With_The_Name : in  Name;
                       Not_Found     : out Boolean)    

위의 내용은 다음과 같이 정의되어야 합니다.

function Is_Valid (...) return Boolean;
procedure Find_Client (With_The_Name: in Name;
                       Found: out Boolean)    

이렇게 하면 클라이언트가 해당 표현식을 필요에 따라 취소할 수 있습니다. 취소에 따른 런타임 불이익은 없습니다.

if not Is_Valid (...) then ....    

경우에 따라, "Is_Not_Valid" 대신 "Is_Invalid"와 같은 반대어를 사용하여 해당 시맨틱을 변경하지 않고도 부정 술부를 긍정으로 만들 수도 있습니다. 그러나 긍정적인 이름이 더 읽기 쉽습니다. 즉, "Is_Valid"가 "not Is_Invalid"보다 이해하기가 쉽습니다.

오케이 표시 아이콘동일한 일반 의미를 나타내는 경우, 동의어 또는 변형이 아닌 동일한 단어를 사용하십시오. 따라서 균일성(Minimal Surprise) 원칙에 따라 오버로드가 권장됩니다.

검지 아이콘서브프로그램을 입력 호출을 위한 "스킨" 또는 "랩퍼"로 사용하는 경우, _Or_Wait를 동사의 접미부로 표시하거나 Wait_For_와 같은 구 다음에 명사를 표시하여 해당 사실을 이름에 반영하는 것이 유용합니다.

Subscriber.Get_Reply_Or_Wait
Subscriber.Wait_For_Reply    

일부 오퍼레이선은 항상 동일한 이름을 사용하여 일관되게 정의됩니다.

검지 아이콘문자열과 유형 간 변환의 경우 대칭 함수:

    function Image and function Value    

검지 아이콘일부 하위 레벨 표현과 유형 간 변환의 경우(예: 데이터 상호 교환의 경우 Byte_String):

    procedure Read and Write    

검지 아이콘할당된 데이터의 경우:

    function Allocate (rather than Create)
    function Destroy (or Release, to express that the object will disappear)    

이 작업이 체계적으로 수행되는 경우, 일관된 이름 지정 규칙을 사용하면 유형을 보다 쉽게 구성할 수 있습니다.

오케이 표시 아이콘활성 반복자의 경우, 다음 기본 요소가 항상 정의되어야 합니다.

Initialize
Next
Is_Done
Value_Of
Reset
. 여러 반복자 유형을 동일한 범위에 사용하는 경우, 각 반복자에 대해 고유한 ID 세트를 사용하는 대신 이러한 기본 요소를 오버로드해야 합니다 ( [BOO87] 참조).

오케이 표시 아이콘Ada의 사전 정의된 속성을 함수 이름으로 사용하는 경우, 동일한 일반 시맨틱('First, 'Last, 'Length, 'Image, 'Value 등)과 함께 사용해야 합니다. 'Range 및 'Delta와 같은 몇몇 속성은 예약어이므로 함수 이름으로 사용할 수 없습니다.

오브젝트 및 서브프로그램(또는 항목) 매개변수

확인 아이콘고유성을 나타내거나 이 엔티티가 조치의 중점 사항임을 표시하려면 오브젝트 또는 매개변수 이름의 접두부로 The_ 또는 This_를 추가하십시오. 2차, 임시, 보조 오브젝트를 나타내려면 다음과 같이 A_ 또는 Current_를 접두부로 추가하십시오.

procedure Change_Name (The_Subscriber : in Subscriber.Handle;
                       The_Name       : in Subscriber.Name );
declare
    A_Subscriber : Subscriber.Handle := Subscriber.First;
begin
    ...
    A_Subscriber := Subscriber.Next (The_Subscriber);
end;    

오케이 표시 아이콘부울 오브젝트의 경우, 술부 절을 긍정적 양식으로 사용하십시오.

Found_It
Is_Available    

 

Is_Not_Available은 사용해서는 안됩니다.

오케이 표시 아이콘타스크 오브젝트의 경우, 활성 엔티티를 의미하는 명사 또는 명사구를 사용하십시오.

Listener
Resource_Manager
Terminal_Driver    

오케이 표시 아이콘매개변수의 경우, 클래스 이름 또는 일부 특성 명사에 전치사를 접두부로 표시하면(특히 이름 지정된 연관을 사용하면) 호출자측에서 읽기 쉬워집니다. 보조 매개변수에 대해 유용한 다른 접두부 양식은 Using_입니다. 또는 부수적인 영향을 받는 in out 매개변수의 경우 Modifying_ 양식을 사용할 수도 있습니다.

procedure Update (The_List     : in out Subscriber.List.Handle;
                  With_Id      : in     Subscriber.Identification;
                  On_Structure : in out Structure;
                  For_Value    : in     Value);
procedure Change (The_Object   : in out Object;
                  Using_Object : in     Object);    

오케이 표시 아이콘매개변수가 정의되는 순서는 호출자 관점에서 매우 중요합니다.

이를 통해 기본 매개변수에 대한 이름 지정 연관을 사용하지 않고 기본값을 이용할 수 있습니다.

오케이 표시 아이콘 "in" 모드는 함수에서도 명시적으로 표시되어야 합니다.

일반 유닛

오케이 표시 아이콘비일반 버전에 사용할 가장 적합한 이름을 선택하고(패키지의 경우 클래스 이름, 프로시저의 경우 타동사 또는 동사구(위의 내용 참조)) 접미부 _Generic을 추가하십시오.

오케이 표시 아이콘일반 정규 유형의 경우, 일반 패키지가 일부 추상 데이터 구조를 정의하는 경우 일반 정규에 대해서는 Item 또는 Element를 사용하고 내보낸 추상에 대해서는 Structure 또는 보다 적합한 다른 명사를 사용하십시오.

오케이 표시 아이콘수동 반복자의 경우, Apply, Scan, Traverse, Process 또는 Iterate와 같은 동사를 ID에 사용하십시오.

generic
		with procedure Act	(Upon : in out Element);
procedure Iterate_Generic	(Upon : in out Structure);    

오케이 표시 아이콘일반 정규 매개변수의 이름은 동형 이의어가 될 수 없습니다.

generic
    type Foo is private;
    type Bar is private;
    with function Image (X : Foo) return String;
    with function Image (X : Bar) return String;
package Some_Generic is ...    

위의 내용은 다음과 같이 변경됩니다.

generic
    type Foo is private;
    type Bar is private;
    with function Foo_Image (X : Foo) return String;
    with function Bar_Image (X : Bar) return String;
package Some_Generic is ...    

필요한 경우, 다음과 같이 일반 정규 매개변수의 이름을 일반 유닛에서 바꿀 수 있습니다.

function Image (Item : Foo) return String Renames Foo_Image;
function Image (Item : Bar) return String Renames Bar_Image;    

서브시스템에 대한 이름 지정 전략

대규모 시스템을 Rational 서브시스템(또는 상호 연결된 프로그램 라이브러리의 다른 양식)으로 파티션하는 경우, 다음이 가능한 이름 지정 전략을 정의하는 것이 유용합니다.

이름 충돌을 피함

수백 개의 오브젝트와 서브오브젝트로 구성되는 시스템에서는 라이브러리-유닛 레벨에서 이름 충돌이 발생할 수 있으며 프로그래머는 Utilities, Support, Definitions 등과 같이 유용한 이름의 동의어를 찾기 어렵습니다.

간편한 Ada 엔티티 찾기

Rational 호스트에서 찾아보기 기능을 사용하는 경우 엔티티가 정의된 위치를 찾는 것은 쉬운 일이지만, 코드가 대상으로 포팅되고 대상 도구(디버거, 테스트 도구 등)를 사용하는 경우 신규 프로젝트 인원이 100개 서브시스템의 2,000개 유닛에서 Utilities.Get 프로시저의 위치를 찾기는 매우 어렵습니다.

오케이 표시 아이콘라이브러리 레벨 유닛 이름에, 포함된 서브시스템의 약어(4자)를 접두부로 추가하십시오.

서브시스템 목록은 소프트웨어 아키텍처 문서(SAD)에서 제공됩니다. 여러 프로젝트, COTS 제품 및 표준 유닛에서 재사용될 가능성이 높은 컴포넌트는 이 규칙 라이브러리에서 제외하십시오.

예제:

Comm(통신)

Dbms(데이터베이스 관리)

Disp(표시)

Math(수리 패키지)

Drive(드라이버)

예를 들어, Disp 서브시스템에서 내보낸 모든 라이브러리 유닛에는 접두부 Disp_가 추가되며 Disp 담당 팀 또는 회사가 원하는 대로 이름을 지정할 수 있습니다. DBMS 및 Disp가 모두 Subscriber 클래스를 사용해야 하는 경우, 다음과 같은 패키지가 생성됩니다.

Disp_Subscriber
Disp_Subscriber_Utilities
Disp_Subscriber_Defs
Dbms_Subscriber
Dbms_Subscriber_Interface
Dbms_Subscriber_Defs    

6장

유형, 오브젝트 및 프로그램 유닛 선언

오케이 표시 아이콘Ada의 강력한 유형 지정 기능을 사용하면 다른 유형이 혼합되는 것을 막을 수 있습니다. 개념상 다른 유형은 다른 사용자 정의 유형으로 인식되어야 합니다. 또한 프로그램을 읽기 쉽게 작성하고 컴파일러로 생성되는 런타임 검사의 효과를 향상시키려면 하위 유형을 사용해야 합니다.

열거 유형

오케이 표시 아이콘가능한 경우, 다음과 같이 초기화되지 않거나 올바르지 않거나 값이 전혀 없음을 나타내는 예비 리터럴 값을 열거에 사용하십시오.

type Mode  is (Undefined, Circular, Sector, Impulse);
type Error is (None, Overflow, Invalid_Input_Value,Ill-formed_Name);    

이는 오브젝트를 체계적으로 초기화하는 규칙을 지원합니다. 이 리터럴을 목록 끝이 아닌 시작 위치에 배치하면 유지보수가 용이할 뿐만 아니라 다음과 같이 올바른 값의 연결 하위 범위가 허용됩니다.

subtype Actual_Error is Error range Overflow .. Error'Last;    

숫자 유형

오케이 표시 아이콘사전 정의된 숫자 유형은 사용하지 마십시오.

높은 수준의 이식성 또는 재사용 가능성이 필요하거나 숫자 오브젝트가 사용하는 메모리 공간에 대한 제어가 필요한 경우, Standard 패키지의 사전 정의된 숫자 유형을 사용해서는 안됩니다. 이 요구사항이 필요한 이유는 사전 정의된 유형인 Integer 및 Float의 특성이 Reference Manual for the Ada Programming Language [ISO87]에 지정되어 있지 않기 때문입니다.

검지 아이콘첫 번째 체계적 전략은 예를 들어 System_Types 패키지에 프로젝트 특정 숫자 유형을 사용하는 것입니다. 다음과 같이 정확도 또는 메모리 크기를 표시하는 이름을 사용할 수 있습니다.

package System_Types is
        type Byte is range -128 .. 127;
        type Integer16 is range -32568 .. 32567;
        type Integer32 is range ...
        type Float6 is digits 6; 
        type Float13 is digits 13;
...
end System_Types;    

검지 아이콘표준 유형(Standard 패키지의 유형)을 재정의하지 마십시오.

검지 아이콘파생될 원본 기본 유형을 지정하지 말고 컴파일러가 선택하도록 하십시오. 다음 예제는 잘못된 예제입니다.

type Byte is new Integer range -128 .. 127;    

검지 아이콘대부분의 시스템에서 32비트 float가 6자리의 정확도를 나타내지만 Float32보다는 Float6이 더 좋은 이름입니다.

검지 아이콘다양한 프로젝트 파트에서, Baty_System_Types의 이름보다 의미있는 이름을 가진 유형을 도출하십시오. 가장 정확한 유형을 개인용으로 작성함으로써 제한적인 정밀도 지원으로도 대상에 대한 최종 포트를 지원할 수 있습니다.

이 전략은 다음과 같은 경우 사용됩니다.

위의 경우에 해당되지 않는 경우, 보다 단순한 다른 전략은 요청된 범위 및 정확도를 지정하되 파생되어야 하는 원본 기본 유형을 지정하지 않고 새 유형을 정의하는 것입니다. 예를 들어, 다음과 같이 선언하십시오.

type Counter is range 0 .. 100;
type Length is digits 5;    

이 선언이 다음 선언보다 바람직합니다.

type Counter is new Integer range 1..100; -- could be 64 bits
type Length is new Float digits 5; -- could be digits 13    

두 번째 전략은 프로그래머가 임의로 특정 비트 수를 선택하는 대신 각 유형에 필요한 정확한 한계와 정확도를 고려하는 것입니다. 그러나 해당 범위가 기본 유형의 범위와 다른 경우, 컴파일러에 의해 체계적 범위 검사가 적용됩니다. 예를 들어, 위의 Counter 유형의 경우 기본 유형은 32비트 정수입니다.

검지 아이콘범위 검사가 문제가 되는 경우, 다음 내용을 선언하여 이를 피할 수 있습니다.

type Counter_Min_Range is range 0 .. 10_000;
type Counter is range Counter_Min_Range'Base'First .. Counter_Min_Range'Base'Last;    

오케이 표시 아이콘표준 유형이 루프, 색인 범위 등과 같은 구조를 통해 코드로 누출되지 않도록 하십시오.

사전 정의된 숫자 유형의 하위 유형은 다음과 같은 상황에서만 사용됩니다.

예제:

for I in 1 .. 100 loop ...     
-- I is of type Standard.Integer
type A is array (0 .. 15) of Boolean; 
-- index is Standard.Integer.    

대신 Some_Integer range L .. H 양식을 사용합니다.

for I in Counter range 1 .. 100 loop ...
type A is array (Byte range 0 .. 15) of Boolean;    

검지 아이콘부호가 없는 유형은 구현하지 마십시오.

부호가 없는 산술이 있는 정수 유형은 Ada에 없습니다. 언어 정의에서는 모든 정수 유형이 사전 정의된 유형에서 간접적으로 파생되거나 파생되지 않습니다. 따라서 이러한 유형은 0을 중심으로 대칭적이어야 합니다.

실제 유형

오케이 표시 아이콘이식성을 위해서는 해당 범위의 값을 갖는 실제 유형에만 의존하십시오.

[-F'Large .. -F'Small]  [0.0]  [F'Small .. F'Large]    

F'Last 및 F'First는 모델 번호가 아닐 수 있으며 어떤 모델 간격에도 속하지 않을 수 있습니다. F'Last 및 F'Large의 상대 위치는 유형 정의 및 기본 하드웨어에 의존합니다. 특히 잘못된 한 가지 예는 고정점 유형의 'Last가 다음과 같은 유형에 속하지 않는 경우입니다.

type FF is delta 1.0 range -8.0 .. 8.0;    

여기서, FF'Last = 8.0은 Ada Reference Manual 3.5.9(6)의 내용에 따라, 유형에 속할 수 없습니다.

크거나 작은 실수를 나타내려면 정수 유형에서와 같이 'First 및 'Last가 아닌 'Large 또는 'Small(및 해당 부정적 대상) 속성을 사용하십시오.

오케이 표시 아이콘부동 소수점 유형의 경우 <= 및 >=만 사용하고, =, <, >, /=는 사용하지 마십시오.

절대 비교 시맨틱이 잘못 정의되었습니다. 즉, 표시는 같지만 필수 정확도 면에서 다릅니다. 예를 들어, X < Y는 not (X >= Y)와 같은 결과를 갖지 않습니다. 동일성에 대한 테스트, A = B는 다음과 같이 표현되어야 합니다.

abs (A - B) <= abs(A)*F'Epsilon    

읽기 쉽게 작성하고 유지보수성을 향상시키려면 위의 표현식을 포함하는 Equal 연산자를 제공할 수 있습니다.

다음과 같이 보다 단순한 표현식을 사용할 수도 있습니다.

abs (A - B) <= F'Small    

이 표현식은 A 값과 B 값이 모두 작은 경우에만 사용할 수 있으므로 일반적으로 권장되지 않습니다.

오케이 표시 아이콘사전 정의된 예외 Numeric_Error에 대한 참조를 사용하지 마십시오. Ada Board의 결합적 해석에 따라 Numeric_Error를 발생시키던 모든 경우에서 Constraint_Error가 발생합니다. Ada 95에서는 Numeric_Error 예외를 더 이상 사용하지 않습니다.

검지 아이콘구현을 통해 Numeric_Error가 계속 발생하는 경우(Rational 기본 컴파일러의 경우), 항상 예외 핸들러의 동일한 대안에서 Constraint_Error와 Numeric_Error를 함께 확인하십시오.

when Numeric_Error | Constraint_Error => ...    

검지 아이콘언더플로우에 유의하십시오.

Ada에서는 언더플로우가 감지되지 않으므로 해당 결과는 0.0이고 예외가 발생하지 않습니다. 언더플로우에 대한 확인은 피연산자 중 0.0이 없을 때 0.0에 대한 곱셈 또는 나눗셈 결과를 테스트하여 명시적으로 수행할 수 있습니다. 또한 약간의 비용은 발생하지만 사용자 고유의 연산자를 구현하여 자동으로 이런 검사를 수행할 수도 있습니다.

손 모양 주의 아이콘고정점 유형의 사용이 제한됩니다.

가능한 경우 부동 소수점 유형을 사용하십시오. Ada 구현에서 고정점 유형에 대한 불규칙적인 구현을 수행하는 경우 이식성 문제가 발생합니다.

검지 아이콘고정점 유형의 경우, 'Small은 'Delta와 동일해야 합니다.

코드에서 이 내용을 지정해야 합니다. 'Small에 대한 기본 선택사항이 power 2인 경우 모든 문제점의 원인이 됩니다. 명확한 선택을 위해서는 다음을 작성해야 합니다.

Fx_Delta : constant := 0.01;
type FX is delta Fx_Delta range L .. H;
for FX'Small use Fx_Delta;    

고정점 유형에 대해 length 절이 지원되지 않는 경우, 이 규칙을 준수하기 위한 방법은 2의 멱인 'Delta를 명시적으로 지정하는 것입니다. 하위 유형에는 'Delta와 다른 'Small이 포함될 수 있습니다(이 규칙은 Ada Reference Manual의 용어집에서 "처음 이름 지정된 하위 유형"이나 유형 정의에만 적용됨).

레코드 유형

오케이 표시 아이콘가능한 경우, 레코드 유형의 컴포넌트에 대해 단순한 정적 초기값을 제공하십시오(일반적으로 'First 또는 'Last와 같은 값을 사용할 수 있음).

그러나 판별식에는 이 규칙을 적용하지 마십시오. 언어 규칙은 판별식이 항상 값을 갖는 것입니다. 가변 레코드(즉, 판별식에 대한 기본값을 포함하는 레코드)는 가변성이 필요한 특성인 경우에만 사용해야 합니다. 그렇지 않은 경우 가변 레코드로 인해 메모리 공간(일반적으로 가장 큰 변형이 할당됨) 및 시간(변형 검사 수행이 보다 복잡함)에 과도한 오버헤드가 발생합니다.

오케이 표시 아이콘컴포넌트의 기본 초기값에서 함수를 호출하지 마십시오. 이렇게 하면, "정제 전 액세스" 오류가 발생할 수 있습니다("프로그램 구조 및 컴파일 문제" 참조).

검지 아이콘가변 레코드(판별식이 기본값을 갖는 레코드)에 대해, 다른 컴포넌트의 크기를 측정할 때 판별식을 사용하려면 가능한 적은 범위에 속하도록 지정하십시오.

예제:

type Record_Type (D : Integer := 0) is 
        record 
            S : String (1 .. D);
        end record;
A_Record : Record_Type;    

위와 같은 경우 대부분의 구현에서 Storage_Error가 발생할 수 있습니다. 판별식 D의 하위 유형에는 보다 적합한 범위를 지정하십시오.

오케이 표시 아이콘레코드의 실제 레이아웃과 관련된 내용을 가정하지 마십시오.

특히, 다른 프로그래밍 언어와 달리 컴포넌트 레이아웃을 정의에 지정된 순서대로 지정하지 않아도 됩니다.

액세스 유형

손 모양 주의 아이콘액세스 유형의 사용을 제한하십시오.

이는 특히 가상 메모리가 없는 소규모 시스템에서 영구적으로 실행될 응용프로그램의 경우에 해당합니다. 작은 프로그래밍 실수라도 저장영역 부족을 일으킬 수 있고 올바른 프로그래밍이라도 메모리를 단편화할 수 있다는 점에서 액세스 유형은 매우 위험합니다. 액세스 유형은 또한 그 속도가 느립니다. 액세스 유형 사용은 프로젝트 전체 전략의 일부여야 하며, 콜렉션, 해당 크기와 할당 및 할당 해제 지점을 추적해야 합니다. 추상 클라이언트에게 액세스 값이 조작된다는 점을 알리려면 선택한 이름에 Pointer 또는 접미부에 _Pointer를 표시해야 합니다.

오케이 표시 아이콘프로그램 정제 과정에서 콜렉션을 할당하고 각 콜렉션의 크기를 체계적으로 지정하십시오.

지정된 값(저장영역 단위)은 정적이거나 동적으로 계산될 수 있습니다(예: 파일에서 읽기). 이 규칙을 적용하는 이유는 프로그램이 N일 후 이유 없이 중단되는 대신 시작 즉시 중단되어야 하기 때문입니다. 일반 패키지는 이를 위해 크기를 지정하는 추가 일반 정규를 제공할 수 있습니다.

할당된 각 오브젝트에는 일반적으로 약간의 오버헤드가 있습니다. 또한 대상 시스템의 런타임은 내부 관리를 위한 각 대용량 메모리와 함께 추가 정보를 할당할 수 있습니다. 따라서 크기가 M인 저장영역 단위의 N개 오브젝트를 저장하려면 콜렉션에 대해 N * M보다 많은 저장영역 단위를 할당해야 합니다(예: N * (M + K)). 이 오버헤드 K의 값은 [ISO87]의 부록 F 또는 실험을 통해 얻을 수 있습니다.

오케이 표시 아이콘할당자(Ada 기본요소 new) 및 릴리스 사용을 캡슐화하십시오. 가능한 경우 Unchecked_Deallocation에 의존하는 대신 내부 여유 목록을 관리하십시오.

액세스 유형을 사용하여 순환 데이터 구조를 구현하는 경우, 동일한 해당 액세스 유형을 컴포넌트로 갖는 레코드 유형에 액세스하게 됩니다. 이러한 경우 추가 공간 오버헤드 없이 해당 유형을 여유 목록에서 연결하여 여유 셀을 재사용할 수 있습니다(목록 헤드에 대한 포인터 제외).

new로 발생한 Storage_Error 예외를 명시적으로 처리하고 콜렉션의 최대 저장영역 크기 부족을 나타내는 보다 의미있는 예외를 다시 내보냅니다.

할당 및 할당 해제를 단일 위치에서 수행함으로써 문제점 발생 시 추적 및 디버깅이 보다 용이합니다.

오케이 표시 아이콘할당 해제는 동일한 크기의 할당된 셀(판별식도 동일)에만 사용하십시오.

이는 메모리 단편화를 막는 데 있어 중요합니다. Unchecked_Deallocation은 메모리 압축 서비스를 제공하지 않습니다. 런타임 시스템이 인접한 해제 블록에 대한 연합을 제공하는지 여부를 확인할 수 있습니다.

오케이 표시 아이콘 Destroy(또는 Free, Release) 기본요소에 액세스 유형을 체계적으로 제공하십시오.

이는 특히 액세스 유형으로 구현되는 추상 데이터 유형에 중요하므로 해당 유형을 여러 개 구성하려면 체계적으로 수행해야 합니다.

오케이 표시 아이콘오브젝트를 체계적으로 해제하십시오.

할당 및 할당 해제에 대한 호출을 맵핑하여 할당된 모든 데이터가 할당 해제되도록 하십시오. 데이터를 처음에 할당된 범위와 동일한 범위에서 할당 해제하십시오. 예외가 발생하는 경우에도 할당 해제하십시오. 이는 raise 문으로 끝나는 when others 대안을 사용하는 한 가지 경우입니다.

선호 전략은 가져오기-사용-해제 패턴을 적용하는 것입니다. 이 경우, 프로그래머는 동적 데이터 구조를 작성하는 오브젝트를 가져와 사용한 다음 해제해야 합니다. 이 세 가지 조작이 코드에 명확히 식별되어야 하며 가능한 모든 프레임 종료 시 해제가 수행되어야 합니다(예외 포함).

검지 아이콘레코드에 포함될 수 있는 임시 컴포지트 데이터 구조를 주의하여 할당 해제하십시오.

예제:

type Object is
record
    Field1: Some_Numeric;
    Field2: Some_String;
    Field3: Some_Unbounded_List;
end record;    

여기서, 'Some_Unbounded_List'는 컴포지트 링크 구조입니다. 즉, 함께 링크된 여러 오브젝트로 구성됩니다. 이제 다음과 같은 일반 속성 함수를 고려하십시오.

function Some_Attribute_Of(The_Object: Object_Handle) return 
Boolean is Temp_Object: The_Object;
begin
    Temp_Object := Read(The_Object);
    return Temp_Object.Field1 < Some_Value;
end Some_Attribute_Of;    

오브젝트가 Temp_Object로 읽힐 때 힙에서 내재적으로 작성된 컴포지트 구조는 할당 해제되지 않지만 도달할 수 없게 됩니다. 이를 메모리 누수라고 합니다. 올바른 솔루션은 이처럼 광범위한 구조에 대해 가져오기-사용-해제 패러다임을 구현하는 것입니다. 즉, 다음과 같이 클라이언트가 먼저 오브젝트를 가져오고 필요에 따라 사용한 다음 해제해야 합니다.

procedure Get (The_Object  : out Object;
               With_Handle : in  Object_Handle);
function Some_Attribute_Of(The_Object : Object) 
                        return Some_Value;
function Other_Attribute_Of(The_Object	: Object) 
                        return Some_Value;
...
procedure Release(The_Object: in out Object);    

클라이언트 코드는 다음과 같습니다.

 declare
    My_Object: Object;
begin
    Get (My_Object, With_Handle => My_Handle);
    ...
    Do_Something
      (The_Value => Some_Attribute_Of(My_Object));
      ...
    Release(My_Object);
end;    

private 유형

오케이 표시 아이콘구현 세부사항을 숨겨야 하는 경우 유형을 private으로 선언하십시오.

다음과 같은 경우 private 유형을 사용하여 구현 세부사항을 숨겨야 합니다.

Rational Environment에서 private 유형은 폐쇄 private 파트 및 서브시스템과 함께 최종 인터페이스 디자인 변경의 영향을 크게 줄여줍니다.

검지 아이콘소위 말하는 "순수" 객체 지향 프로그래밍과 달리 해당 complete 유형이 가능한 가장 올바른 추상인 경우 private 유형을 사용하지 마십시오. 보다 실용적인 관점에서 private 유형을 사용하면 가치가 추가되는지 생각해 보십시오.

예를 들어, 수리 벡터의 경우 배열로 표시되고 면의 점은 레코드로 표시되는 것이 private 유형으로 표시되는 것보다 낫습니다.

type Vector is array (Positive range <>) of Float;
Type Point is 
    record
        X, Y : Float := Float'Large;
    end record;    

배열 색인화, 레코드 컴포넌트 선택 및 집계 표기가 일련의 서브프로그램 호출보다 쉽게 읽을 수 있어 보다 효율적이며 따라서 private 유형을 사용하지 않아도 됩니다.

오케이 표시 아이콘실제 오브젝트 및 값의 기본 지정 또는 비교가 무의미하거나 직관적이지 않거나 불가능한 경우 private 유형을 limited로 선언하십시오.

즉, 다음과 같은 경우입니다.

오케이 표시 아이콘제한된 private 유형은 자체적으로 초기화되어야 합니다.

해당 유형의 오브젝트 선언은 올바른 초기값을 받아야 합니다. 일반적으로 나중에 값을 지정하는 경우 서브프로그램 호출 시 예외가 발생할 수 있기 때문입니다.

검지 아이콘가능하거나 필요한 경우, 제한된 유형에 복사(또는 지정) 프로시저와 삭제 프로시저를 제공하십시오.

검지 아이콘일반 정규 유형을 디자인하는 경우, 해당 일반 유닛의 사용성을 향상시키기 위해 내부적으로 동일성 또는 지정이 필요한 경우가 아니라면 limited private 유형을 지정하십시오.

이전 규칙에 따라 필요한 경우 복사 및 삭제 일반 정규 프로시저와 Are_Equal 술부를 가져올 수 있습니다.

검지 아이콘일반 정규 private 유형의 경우, 해당 실제를 강요해야 하는지 여부를 스펙에 표시하십시오.

이 작업은 다음과 같이 이름 지정 규칙 및/또는 주석을 사용하여 수행할 수 있습니다.

generic
    --Must be constrained.
    type Constrained_Element is limited private;
package ...    

또는 Rational 정의 프라그마(pragma)인 Must_Be_Constrained를 사용할 수 있습니다.

generic
    type Element is limited private;
    pragma Must_Be_Constrained (Element);
package ...    

파생 유형

검지 아이콘유형을 도출하면 상위 유형과 동일한 선언 파트에서 선언되는 모든 서브프로그램 또한 도출됨을 기억하십시오(도출 가능 서브프로그램). 따라서 파생된 유형의 선언 파트에 이들을 모두 스킨으로 재정의할 필요가 없습니다. 그러나 일반 서브프로그램은 도출되지 않으므로 스킨으로 재정의해야 합니다.

예제:

package Base is
    type Foo is
        record
            ...
        end record;
    procedure Put(Item: Foo);
    function Value(Of_The_Image: String) return Foo;
end Base;
with Base;
package Client is
    type Bar is new Foo;
    -- At this point, the following declarations are 
    -- implicitly made:
    -- 
    -- function "="(L,R: Bar) return Boolean;
    -- 
    -- procedure Put(Item: bar);
    -- function Value(Of_The_Image: String) return Bar;
    -- 
end Client;    

따라서 이 오퍼레이션은 스킨으로 재정의할 필요가 없습니다. 그러나 일반 서브프로그램(예: 수동 반복자)은 다른 오퍼레이션과 함께 파생되지 않으므로 스킨으로서 다시 내보내야 합니다. 기본 유형 선언을 포함하는 스펙과 다른 곳에서 정의된 서브프로그램 또한 파생되지 않으므로 스킨으로 다시 내보내야 합니다.

오브젝트 선언

오케이 표시 아이콘오브젝트가 자체적으로 초기화되지 않거나 내재적인 기본 초기값(예: 액세스 유형, 타스크 유형, 비구분 필드에 대한 기본값을 갖는 레코드)이 없는 경우, 오브젝트 선언에 초기값을 지정하십시오.

지정된 값은 단순한 유형 값이 아닌 실제로 의미있는 값이어야 합니다. 입력 매개변수와 같이 실제 초기값을 사용할 수 있는 경우, 해당 값을 지정하십시오. 의미있는 값을 계산할 수 없는 경우, 오브젝트를 나중에 선언하거나 "nil" 값(사용 가능한 경우)을 지정할 수 있습니다.

검지 아이콘"Nil"이라는 이름은 "초기화되지 않음"을 의미하며 알고리즘에서 제어된 방식으로 거부될 수 있는 "사용 불가능하지만 알려진 값"으로 사용될 수 있는 상수를 선언하는 데 사용됩니다.

가능한 경우, Nil 값은 초기화 이외의 다른 용도로 사용해서는 안되며 항상 초기화되지 않은 변수 오류를 나타내야 합니다.

모든 유형(특히 각도와 같은 모듈 유형)에 항상 Nil 값을 선언할 수 있는 것은 아닙니다. 이 경우 덜 가능한 값을 선택하십시오.

검지 아이콘특히 레코드에 변형이 있거나 일부 초기 값이 정적이 아닌 경우(보다 정확하게는 컴파일 시간에 값을 계산할 수 없는 경우) 대용량 레코드를 초기화하는 코드에 비용이 많이 소요될 수 있습니다. 경우에 따라서는 다음과 같이 초기값을 한 번만 설명하고(예: 유형을 정의하는 패키지에) 명시적으로 지정하는 것이 보다 효율적입니다.

R : Some_Record := Initial_Value_For_Some_Record;    

참고:

초기화되지 않은 변수는 코드 포팅과 관련한 문제점의 주요 원인이거나 프로그래밍 오류의 주요 원인으로 알려져 있습니다. 이러한 문제는 개발 호스트에서 프로그래머에게 최소한 일부 오브젝트에 기본값을 제공하거나(예: Rational 원시 컴파일러의 Integer 유형) 프로그램이 로드되기 전에 대상 시스템이 메모리를 0으로 만들 때(예: DEC VAX에서) 악화됩니다. 이식성을 위해서는 항상 최악의 경우를 가정해야 합니다.

검지 아이콘선언에 초기값을 지정하는 것은 비용이 많이 소요되거나 오브젝트를 사용하기 전에 값이 지정되는 경우 생략할 수 있습니다.

예제:

procedure Schmoldu is
    Temp : Some_Very_Complex_Record_Type;
 -- initialized later
begin
    loop
        Temp := Some_Expression ...
        ...    

오케이 표시 아이콘코드에 리터럴 값을 사용하지 마십시오.

정의된 값이 유형과 바인딩되는 경우 상수(유형 포함)를 사용하십시오. 그렇지 않은 경우, 특히 크기를 측정할 수 없는 모든 값(순수 값)에 대해 이름이 지정된 숫자를 사용하십시오.

Earth_Radius : constant Meter := 6366190.7;   -- In meters.
Pi           : constant       := 3.141592653; -- No units.    

검지 아이콘범용 정적 표현식으로 관련 상수를 정의하십시오.

Bytes_Per_Page :   constant := 512;
Pages_Per_Buffer : constant := 10;
Buffer_Size :      constant := Bytes_Per_Page * Pages_Per_Buffer;
Pi_Over_2   :      constant := Pi / 2.0;    

이 경우 해당 표현식을 컴파일 시간에 정확히 계산해야 한다는 사실을 이용하십시오.

오케이 표시 아이콘익명 유형으로 오브젝트를 선언하지 마십시오. 자세한 정보는 Ada Reference Manual 3.3.1을 참조하십시오.

유지보수성이 저하되고 오브젝트를 매개변수로 전달할 수 없어 일반적으로 유형 충돌 오류가 발생합니다.

서브프로그램 및 일반 유닛

검지 아이콘서브프로그램은 프로시저 또는 함수로서 선언할 수 있습니다. 다음은 선언할 양식을 선택하는 데 사용할 수 있는 일반 기준에 대해 설명합니다.

함수를 선언하는 경우는 다음과 같습니다.

프로시저를 선언하는 경우는 다음과 같습니다.

오케이 표시 아이콘구조(테이블, 콜렉션 등)의 크기를 조정하기 위해 사용되는 일반 정규 매개변수에 기본값을 부여하지 마십시오.

오케이 표시 아이콘로컬 프로시저 작성 시 부작용을 최소화하고 함수 작성 시 부작용이 전혀 없게 하십시오. 또한 부작용을 문서화하십시오.

부작용은 일반적으로 글로벌 변수의 수정이며 서브프로그램의 본문을 읽어야만 발견할 수 있습니다. 프로그래머는 호출 위치에서 부작용을 인식할 수 없습니다.

필수 오브젝트를 매개변수로서 전달함으로써 보다 강력하고 쉽게 이해하기 쉬우며 해당 컨텐츠에 대한 종속성이 낮은 코드가 생성됩니다.

이 규칙은 주로 로컬 서브프로그램에 적용됩니다. 내보낸 서브프로그램에는 일반적으로 패키지 본문의 글로별 변수에 대한 올바른 액세스 권한이 필요합니다.


7장

표현식 및 명령문

표현식

검지 아이콘 충분한 괄호를 사용하여 보다 명확한 복합 표현식을 작성하십시오.

표현식의 중첩 레벨은 연산자 우선순위 규칙이 무시된 경우 표현식을 왼쪽에서 오른쪽으로 평가하는 데 필요한 중첩 괄호 세트 수로 정의됩니다.

검지 아이콘표현식의 중첩 레벨을 4로 제한하십시오.

오케이 표시 아이콘레코드 집계는 이름이 지정된 연관을 사용해야 하며 다음과 같이 규정되어야 합니다.

Subscriber.Descriptor'(Name    => Subscriber.Null_Name,
                       Mailbox => Mailbox.Nil,
                       Status  => Subscriber.Unknown,
                   ...);    

검지 아이콘레코드 집계에는 when others를 사용할 수 없습니다.

이는 배열과 달리 레코드는 그 특성이 이기종 구조이므로 동질의 지정이 바람직하지 않기 때문입니다.

검지 아이콘다음과 같이 단순 술부에는 "if...then...else" 문 대신 단순 부울 표현식을 사용하십시오.

function Is_In_Range(The_Value: Value; The_Range: Range)
         return Boolean is 
         begin 
            if The_Value >= The_Range.Min and The_Value <= The_Range.Max then return True; 
            end if; 
         end Is_In_Range;

다음을 사용하는 것이 보다 바람직합니다.

function Is_In_Range(The_Value: Value; The_Range: Range)
     return Boolean is
begin
    return The_Value >= The_Range.Min 
        and The_Value <= The_Range.Max;
end Is_In_Range;    

읽기 쉬운 정도에 영향을 주는 경우 두 개 이상의 if 문을 포함하는 복잡한 표현식을 이러한 방식으로 변경해서는 안됩니다.

명령문

오케이 표시 아이콘다음과 같은 경우 loop 문에 이름을 지정해야 합니다.

Forever: loop
   ...
end loop Forever;    

오케이 표시 아이콘loop 문에 이름이 있는 경우 포함된 exit 문으로 해당 이름을 지정해야 합니다.

오케이 표시 아이콘시작 시 완료 테스트가 필요한 루프는 "while" 루프 양식을 사용해야 합니다. 다른 곳에서 완료 테스트가 필요한 루프는 일반 양식과 exit 문을 사용해야 합니다.

검지 아이콘루프에서 exit 문의 수를 최소화하십시오.

오케이 표시 아이콘배열에서 반복되는 "for" 루프의 경우, 명시적인 범위 또는 다른 하위 유형 대신 배열 오브젝트에 적용되는 'Range 속성을 사용하십시오.

검지 아이콘루프 종속 코드를 루프에서 제거하십시오. "코드 호이스팅"이 공통 컴파일러 최적화이지만 불변 코드가 다른 컴파일 단위를 호출할 때는 이를 수행할 수 없습니다.

예제:

World_Search:
while not World.Is_At_End(World_Iterator) loop
    ...
    Country_Search:
    while not Nation.Is_At_End(Country_Iterator) loop
    declare
        City_Map: constant City.Map := City.Map_Of
            (The_City => Nation.City_Of(Country_Iterator),
             In_Atlas => World.Country_Of(World_Iterator).Atlas);
    begin
        ...    

위의 코드에서, "World.Country_Of"에 대한 호출은 루프에 독립적입니다(즉, 내부 루프에서 country가 변경되지 않음). 그러나 대부분의 경우 컴파일러는 루프에서 호출을 제거할 수 없습니다. 호출의 부작용으로 프로그램 실행에 영향을 줄 수 있기 때문입니다. 따라서 코드는 루프를 통과할 때마다 불필요하게 실행됩니다.

루프를 다음과 같이 재작성하면 보다 쉽고 효율적으로 이해하고 유지보수할 수 있습니다.

Country_Search:
while not World.Is_At_End(World_Iterator) loop
    declare
        This_Country_Atlas: constant Nation.Atlas 
            := World.Country_Of
                    (World_Iterator).Atlas;
    begin
        ...
        City_Search:
        while not Nation.Is_At_End (The_City_Iterator) loop
            declare
                City.Map_Of (
                    The_City => Nation.City_Of
                                        (Country_Iterator),
                    In_Atlas => This_Country_Atlas );
            begin
                ...    

오케이 표시 아이콘서브프로그램 및 입력 호출은 이름이 지정된 연관을 사용해야 합니다.

그러나 첫 번째(또는 유일한) 매개변수가 오퍼레이션의 중점 사항인 경우(예: 타동사의 직접 목적어), 이 매개변수에 대한 이름만 생략할 수 있습니다.

Subscriber.Delete (The_Subscriber => Old_Subscriber);    

여기서, Subscriber.Delete는 타동사이며 Old_Subscriber는 직접 목적어입니다. 이름 지정된 표현식인 The_Subscriber => Old_Subscriber가 없는 다음 표현식을 사용할 수 있습니다.

Subscriber.Delete	(Old_Subscriber);
Subscriber.Delete (Old_Subscriber, 
                   Update_Database  => True,
                   Expunge_Name_Set => False);
if Is_Administrator (Old_Subscriber) then ...    

매개변수의 의미가 너무 명확해서 이름이 지정된 연관으로 읽기 어려워지는 경우도 있습니다. 예를 들어, 다음과 같이 모든 매개변수의 유형 및 모드가 동일하고 기본값이 없는 경우입니다.

if Is_Equal (X, Y) then ...
Swap (U, B);    

오케이 표시 아이콘case 문 또는 레코드 유형 정의 when others를 사용해서는 안됩니다(변형에 대해).

when others를 사용하지 않으면 불연속 유형 정의가 수정될 때마다 이러한 구조를 올바르지 않게 만들어 프로그래머가 수정 처리를 위해 수행할 내용을 고려하게 함으로써 유지보수 단계를 도와줍니다. 그러나 선택자가 큰 정수 범위인 경우에는 사용할 수 있습니다.

검지 아이콘분기 조건이 불연속 값인 경우 일련의 "elsif" 대신 case 문을 사용하십시오.

오케이 표시 아이콘서브프로그램은 단일 리턴 지점을 있어야 합니다.

명령문 파트가 끝나면 서브프로그램에서 종료하십시오. 함수에는 단일 return 문이 필요합니다. 함수 본문에 return 문이 너무 많은 경우 goto 문과 유사하여 코드를 읽거나 유지보수하기가 어렵습니다.

프로시저에는 return 문이 전혀 없어야 합니다.

검지 아이콘return 문을 여러 번 사용할 수 있는 경우는 모든 return 문을 동시에 볼 수 있고 코드 구조가 매우 일반적이며 아주 짧은 함수인 경우뿐입니다.

function Get_Some_Attribute return Some_Type is
begin
    if Some_Condition then
        return This_Value;
    else
        return That_Other_Value;
    end if;
end Get_Some_Attribute;    

손 모양 주의 아이콘goto 문 사용을 제한하십시오.

"goto" 문과 관련하여, Ada에서의 goto 사용에 대한 제한 조건과 goto 레이블 구문으로 인해 명령문이 덜 위험해지며 많은 경우 이와 동등한 구조(예: 예외가 있는 유사 goto 빌드)보다 선호되고 읽기 쉬우며 의미가 있음에 유의하십시오.

코딩 힌트

검지 아이콘배열을 조작할 때 해당 색인이 1부터 시작한다고 가정하지 마십시오. 'Last, 'First, 'Range 속성을 사용하십시오.

검지 아이콘다음과 같이 비제한 유형(일반적으로 레코드)의 가장 일반적인 제한 하위 유형을 정의하고, 매개변수와 리턴값에 대해 해당 하위 유형을 사용하여 클라이언트 코드에서의 자체 검사 기능을 향상시키십시오.

type Style is (Regular, Bold, Italic, Condensed);
type Font (Variety: Style) is ...
subtype Regular_Font is Font (Variety => Regular);
subtype Bold_Font is Font (Variety => Bold);
function Plain_Version (Of_The_Font: Font) return Regular_Font;
procedure Oblique (The_Text   : in out Text;
                   Using_Font : in     Italic_Font);
...    

8장

가시성 문제

오버로드 및 동형 이의어

권장 가이드라인은 다음과 같습니다.

오케이 표시 아이콘서브프로그램을 오버로드하십시오.

그러나 동일한 ID를 사용하는 경우 실제로 동일한 유형의 오퍼레이션을 의미하는지 확인하십시오.

오케이 표시 아이콘중첩된 범위에서 동형 이의어 ID를 숨기지 마십시오.

이러한 경우 사용자의 혼란이 가중되어 잠재적인 유지보수 위험성이 발생할 수 있습니다. 또한 "for" 루프 제어 변수의 범위와 존재 여부를 확인하십시오.

오케이 표시 아이콘하위 유형이 아닌 유형에 대해 오퍼레이션을 오버로드하십시오.

경험이 부족한 사용자가 알고 있는 내용과는 달리 기본 유형 및 모든 해당 하위 유형에 오버로드가 적용됩니다.

예제:

subtype Table_Page is Syst.Natural16 range 0..10;
function "+"(Left, Right: Table_Page) return Table_Page;    

컴파일러는 서브프로그램과 일치하는 유형을 찾을 때 매개변수의 하위 유형이 아닌 기본 유형을 검색합니다. 따라서 위의 예제에서, "+"는 실제로 Table_Page가 아닌 현재 패키지의 모든 Natural16 값에 대해 재정의됩니다. 따라서 임의 표현식 "Natural16 + Natural16"은 "+"(Table_Page, Table_Page)에 대한 호출로 맵핑되어 잘못된 결과를 리턴하거나 예외를 생성합니다.

컨텍스트 절

오케이 표시 아이콘 "with" 절로 인한 종속성 수를 최소화하십시오.

"with" 절을 사용하여 가시성이 확장되는 경우, 이 절에 해당하는 코드 영역을 가능한 최소화해야 합니다. "with" 절은 반드시 필요한 경우에만 본문 또는 대형 본문 스텁에 사용하십시오.

인터페이스 패키지를 사용하여 하위 레벨 엔티티를 다시 내보냄으로써 "with"로 많은 하위 레벨 패키지를 표시하지 않도록 하십시오. 이렇게 하려면 Environment 명령 패키지에서와 같이, 파생된 유형, 이름 바꾸기, 스킨 서브프로그램 및 문자열과 같이 사전 정의된 유형을 사용하십시오.

유닛 간에는 "with" 절을 사용한 하드(강한) 결합보다 일반 정규 매개변수를 사용한 소프트(약한) 결합을 사용하십시오.

예제: 컴포지트 유형에 대해 Put 프로시저를 내보내려면 Text_Io에 대해 직접 with를 실행하는 대신 해당 컴포넌트에 대한 Put 프로시저를 일반 정규로 가져오십시오.

오케이 표시 아이콘"use" 절을 사용해서는 안됩니다.

컨텍스트를 효과적으로 사용하는 이름 지정 규칙과 해당 이름 바꾸기를 통해 이 규칙을 올바르게 지원하는 경우 가능한 "use" 절을 사용하지 않아야 읽기 쉬워집니다 (위의 "이름 지정 규칙" 참조). 또한 특히 유지보수 단계에서 일관성이 유지됩니다.

문자 유형을 정의하는 패키지의 경우, "use" 절은 이 문자 유형에 따라 문자열을 정의해야 하는 모든 컴파일 단위에서 필요합니다.

package Internationalization is
    type Latin_1_Char is (..., 'A', 'B', 'C', ..., U_Umlaut, ...);
    type Latin_1_String is array (Positive range <>) of 
            Latin_1_Char;
end Internationalization ;
use Internationalization;
Hello : constant Latin_1_String := "Baba"    

"use" 절이 없으면 삽입 양식에서 연산자를 사용하지 않습니다. 클라이언트 유닛에서는 다음과 같이 이름을 바꿀 수 있습니다.

function "=" (X, Y : Subscriber.Id) return Boolean 
            renames Subscriber."=";
function "+" (X, Y :Base_Types.Angle) return Base_Types.Angle
            renames Base_Types."+";    

오케이 표시 아이콘 "use" 절이 없는 경우 일반적으로 여러 클라이언트 유닛에 동일한 이름 바꾸기 세트가 포함되므로, 해당 이름 바꾸기는 모두 정의 패키지에 중첩된 Operations 패키지를 사용하여 정의 패키지에 구성할 수 있습니다. Operations 패키지의 "use" 절은 다음과 같은 클라이언트 유닛에서 권장됩니다.

package Pack is
    type Foo is range 1 .. 10;
    type Bar is private;
     ...
    package Operations is
        function "+" (X, Y : Pack.Foo) return Pack.Foo 
                renames Pack."+";
        function "=" (X, Y : Pack.Foo) return Boolean 
                renames Pack."=";
        function "=" (X, Y : Pack.Bar) return Boolean 
                renames Pack."=";
        ...
    end Operations;
private
	...
end Pack;
with Pack;
package body Client is
    use Pack.Operations; -- Makes ONLY Operations directly visible.
    ...
    A, B : Pack.Foo;    -- Still need prefix Pack.
    ...
    A := A + B ;        -- Note that "+" is directly 
                        -- visible.    

Operations 패키지는 항상 이 이름을 사용해야 하며 항상 정의 패키지에서 표시 가능한 파트의 맨 아래에 배치되어야 합니다. "use" 절은 필요한 곳에만 배치해야 합니다. 즉, 일반적으로 스펙에서 오퍼레이션을 사용하지 않는 경우에만 Client 본문에 배치해야 합니다.

with Defs;
package Client is
    ...
    package Inner is
        use Defs;
        ...
    end Inner;		-- The scope of the use clause ends here.
    ...
end Client;
declare
    use Special_Utilities;
begin
    ...
end;                -- The scope of the use clause ends here.    

이름 바꾸기

검지 아이콘이름 바꾸기 선언을 사용하십시오.

코드를 읽기 쉽게 하려면 "use" 절 제한과 함께 이름 바꾸기가 권장됩니다. 긴 이름이 있는 유닛을 여러 번 참조하는 경우, 다음과 같이 짧은 이름을 제공하면 읽기 쉬워집니다.

with Directory_Tools;
with String_Utilities;
with Text_Io;
package Example is
    package Dt renames Directory_Tools;
    package Su renames String_Utilities;
    package Tio renames Text_Io;
    package Dtn renames Directory_Tools.Naming;
    package Dto renames Directory_Tools.Object;
        ...    

오케이 표시 아이콘프로젝트 전체에서 짧은 이름을 선택함으로써 균일성(Minimal Surprise) 원칙을 준수할 수 있습니다. 이를 위해서는 다음과 같이 패키지에 짧은 이름을 제공해야 합니다.

package With_A_Very_Long_Name is package Vln renames 
            With_A_Very_Long_Name;
    ...
end
with With_A_Very_Long_Name;
package Example is package Vln renames With_A_Very_Long_Name;
-- From here on Vln is an abbreviation.    

패키지 이름 바꾸기는 이름 바꾸기 패키지의 표시 가능한 파트에만 가시성을 제공합니다.

오케이 표시 아이콘가져온 패키지 이름 바꾸기는 선언 파트 시작 위치에서 그룹화되고 영문자 순서대로 정렬되어야 합니다.

검지 아이콘이름 바꾸기는 읽기 쉽게 하는데 도움이 되는 모든 부분에서 로컬로 사용할 수 있습니다. 이로 인한 런타임 불이익은 없습니다. 유형은 제한 없이 하위 유형으로서 이름을 바꿀 수 있습니다.

주석에 대한 섹션에서 설명된 대로, 이름 바꾸기를 사용하면 일반적으로 명확하고 유지보수 가능한 방식으로 코드를 문서화할 수 있어 복잡한 오브젝트에 단순 이름을 제공하거나 유형의 의미를 로컬로 세분화할 수 있습니다. 이름 바꾸기 ID의 범위는 혼동을 피하도록 선택해야 합니다.

검지 아이콘이름 바꾸기 예외를 사용하면 여러 유닛에 예외를 구성할 수 있습니다(예: 일반 패키지의 모든 인스턴스화 사이). 유형을 도출하는 패키지의 경우, 파생 서브프로그램에 의해 잠재적으로 발생하는 예외는 파생 유형과 함께 다시 내보내야만 클라이언트가 원래 패키지를 "포함"하지 않아도 됩니다.

with Inner_Defs; 
package Exporter is ... 
procedure May_Raise_Exception; -- Raises exception Inner_Defs.Bad_Schmoldu when ... ... 
Bad_Schmoldu : exception renames Inner_Defs.Bad_Schmoldu; ...

검지 아이콘매개변수에 대한 기본값이 다른 서브프로그램을 이름을 바꾸면 코드를 간단하게 구성하여 읽기 쉽게 작성할 수 있습니다.

procedure Alert (Message : String;
                 Beeps   : Natural);
procedure Bip (Message : String := "";
               Beeps   : Natural := 1) 
        renames Alert;
procedure Bip_Bip (Message : String := "";
                   Beeps   : Natural := 2) 
        renames Alert;
procedure Message (Message : String;
                   Beeps   : Natural := 0)
        renames Alert;
procedure Warning (Message : String;
                   Beeps   : Natural := 1)
        renames Alert;    

오케이 표시 아이콘이름 바꾸기 선언의 근접 범위에서 이름 바꾸기 엔티티의 이름(이전 이름)을 사용하지 마십시오. 이름 바꾸기 선언에서 도입되는 ID 또는 연산자 기호(새 이름)만 사용하십시오.

use 절에 대한 참조사항

Ada 커뮤니티에서는 오랫 동안 "use" 절에 대한 논의가 끊이지 않고 있으며 때때로 신념에 대한 문제로 발전하기도 했습니다. 양쪽 모두 대규모 프로젝트를 다루지 않거나 너무 비현실적이거나 바람직하지 않은 예제를 사용해 왔습니다.

"use" 절을 지지하는 사용자는 이 절을 사용하면 읽기 쉽게 작성할 수 있다고 주장하며, 특히 읽기 어렵고 긴 중복 이름을 여러 번 사용하는 경우 이름 바꾸기를 통해 이점을 얻을 수 있다는 예제를 제공합니다. 이들은 또한 Ada 컴파일러를 통해 오버로드 문제를 해결할 수 있지만 대규모 Ada 프로그램을 사용하는 사용자가 컴파일러만큼 안전하고 신속하게 오버로드를 해결할 수는 없다고 주장합니다. 이들은 Rational Environment와 같은 정교한 APSE는 명확하고 완전한 이름을 필요없게 만든다고 주장하지만 실제로는 그렇지 않습니다. 즉, 사용자는 확실하지 않은 각 ID에 대한 [정의]를 누르지 않아도 됩니다. 사용자는 사용되는 오브젝트 및 추상을 가정할 필요는 없지만 이를 즉시 확인할 수는 있어야 합니다. "use" 절의 지지자들은 또한 프로그램 유지보수와 관련된 잠재적 위험을 부정하며 그러한 위험을 일으키는 프로그래머에게는 F 학점을 주어야 한다고 주장합니다. 실제로, 그러한 위험은 완전한 이름으로 해결할 수 있습니다.

위에서 "use" 절에 대한 제한에 따른 영향을 완화하기 위해 제안하는 방법이 너무 많은 입력 작업을 필요로 한다고 생각되는 경우, "프로그램을 입력할 때 절감한 시간은 프로그램을 검토, 디버깅 및 유지보수할 때 잃게 된다"라는 Norman H. Cohen의 의견을 참고하십시오.

마지막으로 대규모 시스템에서 "use" 절이 없는 경우, 기호 테이블의 찾아보기 오버헤드가 감소하여 컴파일 시간이 향상되는 것으로 알려져 있습니다.

use 절과 관련된 논쟁에 대해 관심이 있는 사용자는 다음 문헌을 참조하시기 바랍니다.

D. Bryan, "Dear Ada," Ada Letters, 7, 1, January-February 1987, pp. 25-28.

J. P. Rosen, "In Defense of the Use Clause," Ada Letters, 7, 7, November-December 1987, pp. 77-81.

G. O. Mendal, "Three Reasons to Avoid the Use Clause," Ada Letters, 8, 1, January-February 1988, pp. 52-57.

R. Racine, "Why the Use Clause Is Beneficial," Ada Letters, 8, 3, May-June 1988, pp. 123-127.

N. H. Cohen, Ada as a Second Language, McGraw-Hill (1986), pp. 361-362.

M. Gauthier, Ada-Un Apprentissage, Dunod-Informatique, Paris (1989), pp. 368-370.]


9장

프로그램 구조 및 컴파일 문제

패키지 분할

대규모 "논리" 패키지를 분해하기 위한 두 가지 방법은 다음과 같습니다. 이는 초기 디자인 단계에서 관리, 컴파일, 유지보수 및 이해하기 쉬운 작은 여러 Ada 라이브러리 유닛으로 생성됩니다.

a) 중첩 분해

이 접근 방식은 Ada 서브유닛 및/또는 서브패키지를 강조합니다. 주요 서브프로그램, 타스크 본문 및 내부 패키지 본문이 체계적으로 분리되며 해당 서브유닛/서브패키지에서 프로세스가 순환 반복됩니다.

b) 수평 분해

논리 패키지가 "with" 절로 상호 연결된 작은 패키지의 네트워크로 분해되며, 원래 논리 패키지는 대부분 다시 내보내기 스킨(또는 더 이상 존재하지 않는 디자인 아티팩트)입니다.

각 접근 방식에는 나름대로의 장단점이 있습니다. 중첩 분해 방법에서는 많은 ID에서 접두부가 필요하지 않으므로 코드를 적게 작성할 수 있으며 이름 지정도 간단합니다. 또한 Rational Environment의 경우, 라이브러리 이미지에서 해당 구조가 명확히 표시되어 구조를 쉽게 변환할 수 있습니다(Ada.Make_Separate, Ada.Make_Inline 명령). 수평 분해 방법은 일반적으로 재컴파일 작업이 적으며 특히 서브시스템 경계에서 구조가 우수하고 명확합니다. 또한 재사용을 활성화합니다. 또한 자동 재컴파일 도구 및 형상 관리를 사용하여 쉽게 관리할 수 있습니다. 그러나 수평 구조의 경우, 분해 과정에서 작성된 하위 레벨 패키지 중 일부에 "with"가 실행되어 원래 디자인을 위반할 수 있는 심각한 위험성이 있습니다.

오케이 표시 아이콘중첩 레벨은 서브프로그램에 대해 세 개, 패키지에 대해 두 개로 제한되어야 하므로 패키지를 서브프로그램 내에 중첩시키지 마십시오.

package Level_1 is
    package Level_2 is
package body Level_1 is
    procedure Level_2 is
        procedure Level_3 is    

검지 아이콘다음과 같은 경우 중첩 유닛("별도 본문")에 본문 스텁을 사용하십시오.

선언 파트 구조

패키지 스펙

오케이 표시 아이콘패키지 스펙의 선언 파트에는 다음 시퀀스에 따라 배열되어야 하는 선언이 포함됩니다.

1) 패키지 자체에 대한 이름 바꾸기 선언

2) 가져온 엔티티에 대한 이름 바꾸기 선언

3) "use" 절

4) 이름 지정된 숫자

5) 유형 및 하위 유형 선언

6) 상수

7) 예외 선언

8) 내보낸 서브프로그램 스펙

9) 중첩된 패키지(있는 경우)

10) private 파트

검지 아이콘여러 주요 유형을 사용하는 패키지의 경우, 다음과 같이 여러 가지 관련 선언 세트를 갖는 것이 바람직합니다.

5) A에 대한 유형 및 하위 유형 선언

6) 상수

7) 예외 선언

8) A에 대한 오퍼레이션을 위해 내보낸 서브프로그램 스펙

5) B에 대한 유형 및 하위 유형 선언

6) 상수

7) 예외 선언

8) B에 대한 오퍼레이션을 위해 내보낸 서브프로그램 스펙

기타

검지 아이콘선언 파트가 긴 경우(100행 초과), 작은 주석 블록을 사용하여 다양한 섹션을 분리하십시오.

패키지 본문

오케이 표시 아이콘패키지 본문 선언의 선언 파트에는 다음 시퀀스에 따라 배열되어야 하는 선언이 포함됩니다.

1) 이름 바꾸기 선언(가져온 엔티티의 경우)

2) "use" 절

3) 이름 지정된 숫자

4) 유형 및 하위 유형 선언

5) 상수

6) 예외 선언

7) 로컬 서브프로그램 스펙

8) 로컬 서브프로그램 본문

9) 내보낸 서브프로그램 본문

10) 중첩된 패키지 본문(있는 경우)

기타 구조

오케이 표시 아이콘서브프로그램 본문, 타스크 본문 및 블록 명령문과 같은 기타 선언 파트에서는 동일한 일반 패턴을 따릅니다.

컨텍스트 절

오케이 표시 아이콘가져온 라이브러리 유닛 당 하나의 "with" 절만 사용하십시오. with 절은 영문자 순서대로 정렬하십시오. "with" 유닛에 "use" 절이 적합한 경우, 해당 "with" 절 바로 다음에 표시되어야 합니다. 프라그마(pragma) Elaborate은 다음 내용을 참조하십시오.

정제 순서

오케이 표시 아이콘특정 효과를 얻기 위해 라이브러리 유닛의 정제 순서에 의존하지 마십시오.

각 Ada 구현에서 정제 순서를 계산하기 위한 전략을 선택할 수 있습니다. 이 경우, Ada Reference Manual [ISO87]에서 설명하는 간단한 규칙을 충족시켜야 합니다. 일부 구현에서는 다른 구현보다 효과적인 전략(예: 해당 스펙 이후 최대한 빨리 본문 정제)을 사용하지만 일부 구현(특히 일반 인스턴스화의 경우)은 이러한 효과적인 전략을 사용하지 않아 심각한 이식성 문제가 발생할 수 있습니다.

프로그램 정제 과정에서 잘못된 "정제(Elaboration) 전 액세스" 오류가 발생하는 주요 원인은 다음과 같습니다. 이러한 오류는 일반적으로 Program_Error 예외를 발생시킵니다.

task type T;
type T_Ptr is access T;
SomeT : T_Ptr := new T; -- Access before elaboration.    

오케이 표시 아이콘하나의 Ada 컴파일러에서 다른 컴파일러로의 응용프로그램 포팅 문제점이 발생하지 않도록 하려면 프로그래머가 코드를 재구성하여 문제점을 제거하거나(불가능한 경우도 있음) 다음과 같은 전략을 통해 프라그마(pragma) Elaborate을 사용하여 정제 순서를 명시적으로 제어해야 합니다.

다음과 같은 경우 유닛 Q의 컨텍스트 절에서, 프라그마(pragma) Elaborate은 "with" 절에 표시되는 각 유닛 P에 적용되어야 합니다.

또한 P가 유형 T를 내보내 유형 T의 오브젝트 정제 시 패키지 R에서 함수를 호출하는 경우, Q의 컨텍스트 절에는 다음 내용이 포함되어야 합니다.

with R;
pragma Elaborate (R);    

이는 Q에서 R을 직접 참조하지 않는 경우에도 해당됩니다.

실제로, 다음과 같이 패키지 P가 포함해야 하는 규칙을 설명하는 것이 더 쉬울 수도 있습니다(불가능한 경우도 있음).

with R; 
pragma Elaborate (R);

패키지 Q는 다음 내용을 전달해야 합니다.

with P;
pragma Elaborate (P);    

이를 통해 결과적으로 이행성에 따른 올바른 정제 순서를 제공하게 됩니다.


10장

동시성

손 모양 주의 아이콘타스크 사용을 제한하십시오.

타스크는 매우 강력한 기능이지만 사용 시 주의가 필요합니다. 타스크를 올바르게 사용하지 않는 경우 공간 및 시간과 관련된 과도한 오버헤드가 발생할 수 있습니다. 시스템의 특정 파트를 약간만 변경해도 타스크 세트의 기능에 나쁜 영향을 주어 결핍 및/또는 교착 상태가 발생할 수 있습니다. 프로그램의 타스크 작업에 대한 테스트 및 디버깅은 매우 어려운 작업입니다. 따라서 타스크 사용, 해당 위치 및 상호작용은 프로젝트 레벨에서 결정해야 합니다. 타스크는 숨겨서 사용하거나 경험이 부족한 프로그래머가 작성해서는 안됩니다. Ada 프로그램의 타스크 모델은 누구나 확인할 수 있고 이해할 수 있어야 합니다.

병렬 하드웨어로부터의 효과적인 지원이 없는 경우, 동시성이 반드시 필요한 경우에만 타스크를 사용해야 합니다. 이는 주기적 활동, 제한시간 사용이나 외부 메시지 도착 및 인터럽트와 같은 외부 이벤트 등 시간에 의존하는 조치를 표현하는 경우입니다. 타스크는 또한 공통 자원에 대한 액세스 버퍼링, 대기열 지정, 디스패치 및 동기화와 같은 기타 활동을 해체하는 데 사용되어야 합니다.

오케이 표시 아이콘Storage_Size length 절을 사용하여 타스크 스택 크기를 지정하십시오.

콜렉션에서 length 절을 사용해야 하는 동일한 상황과 이유로(위의 "액세스 유형" 섹션 참조), 메모리가 중요한 자원인 경우 타스크 크기를 지정해야 합니다. 이를 위해서는 항상 명시적으로 선언된 유형의 타스크를 선언해야 합니다. length 절은 유형에만 적용할 수 있기 때문입니다. 함수 호출을 사용하여 스택 크기를 동적으로 조정할 수도 있습니다.

참고: 각 타스크에서 필요한 스택 크기를 예상하는 것은 매우 어렵습니다. 이를 위해서는 "정점" 메커니즘을 사용하여 런타임 시스템을 관리할 수 있어야 합니다.

오케이 표시 아이콘타스크 본문에서 예외 핸들러를 사용하여 설명되지 않은 타스크 정지를 피하거나 최소한 해당 내용을 보고하십시오.

예외를 처리하지 않는 타스크는 일반적으로 자동 정지됩니다. 가능한 경우, 해당 원인(특히 Storage_Error)을 보고해야 하며 이를 통해 스택 크기를 정밀하게 조정할 수 있습니다. 이렇게 하려면 Storage_Error 이외의 예외를 다시 내보내는 서브프로그램에 할당(새 기본요소)을 캡슐화해야 합니다.

오케이 표시 아이콘프로그램 정제 과정에서 타스크를 작성하십시오.

프로그램 정제 과정에서 콜렉션을 할당해야 하는 동일한 상황과 이유로(위의 ("액세스 유형" 섹션 참조), 프로그램 시작 시 최대한 빨리 전체 응용프로그램 타스크 구조를 작성해야 합니다. 프로그램이 며칠 후 중단되는 것보다는 메모리 사용 문제가 있어서 프로그램이 전혀 시작되지 않는 것이 낫습니다.

이후 규칙에서는 서비스 타스크와 응용프로그램 타스크를 구분합니다. 서비스 타스크는 응용프로그램 관련 타스크 간에 "연결 기능"을 제공하는 데 사용되며 짧고 간단한 알고리즘의 타스크입니다. 서비스 타스크(또는 중개 타스크)의 예로는 일반적으로 동기화, 해체, 버퍼링 및 대기 서비스를 제공하는 버퍼, 전송자, 릴레이, 에이전트, 모니터 등이 포함됩니다. 응용프로그램 타스크는 이름에서 알 수 있듯이 응용프로그램의 기본 기능과 보다 직접적인 관련이 있습니다.

오케이 표시 아이콘혼성 타스크는 수행하지 않습니다. 응용프로그램 타스크는 순수 호출자로 작성되어야 하며 서비스 타스크는 순수 피호출자로 작성되어야 합니다.

순수 피호출자는 입력 호출 없이 accept 문 또는 선별적 대기만을 포함하는 타스크입니다.

오케이 표시 아이콘입력 호출 그래프에서 순환성을 피하십시오.

이를 통해 교착 상태의 위험성을 현저히 줄일 수 있습니다. 순환성을 완전히 피할 수 없는 경우라도 최소한 시스템 안정 상태에서는 피해야 합니다. 이 두 가지 규칙을 따르면 구조를 보다 쉽게 이해할 수 있습니다.

손 모양 주의 아이콘공유 변수 사용을 제한하십시오.

숨겨진 공유 변수, 즉 예를 들어, 여러 타스크에 표시되는 기본요소가 액세스하는 패키지 본문에서 숨겨진 변수에 유의해야 합니다. 공유 변수는 랑데뷰에 따른 비용이 너무 높은 경우, 공통 데이터 구조에 대한 액세스를 동기화하기 위한 극단적인 경우에 사용할 수 있습니다. 프라그마(pragma) Shared가 효과적으로 지원되는지 여부를 확인하십시오.

손 모양 주의 아이콘abort 문 사용을 제한하십시오.

abort 문은 가장 위험하고 유해한 언어 기본요소 중 하나로 알려져 있습니다. 이 명령문은 아무 조건 없이(또한 거의 비동기식으로) 타스크를 종료하므로 특정 타스크 구조의 동작을 추론하는 것이 거의 불가능합니다. 그러나 예외적으로 abort 문이 필요한 경우도 있습니다.

예제: 제한시간 기능이 없는 일부 하위 레벨 서비스가 제공되는 경우입니다. 제한시간 기능을 사용하려면 특정 보조 에이전트 타스크에서 제공하는 서비스가 에이전트로부터의 응답을 대기하도록 지시하고 제한시간을 지정한 다음 해당 지연 시간 안에 서비스가 제공되지 않으면 abort 문에 따라 에이전트가 중단되도록 해야 합니다.

중단자 및 피중단자만 영향을 받는 경우, 즉 다른 타스크가 중단된 타스크를 호출할 수 없는 경우에만 abort 문을 사용할 수 있습니다.

손 모양 주의 아이콘delay 문 사용을 제한하십시오.

타스크를 임의로 일시중단하는 경우 여러 가지 스케줄 문제점이 발생할 수 있으며 이러한 문제점은 추적 및 정정이 매우 어렵습니다.

손 모양 주의 아이콘'Count, 'Terminated 및 'Callable 속성 사용을 제한하십시오.

'Count 속성은 대략적인 표시로만 사용되어야 하며 해당 값이 0인지 아닌지 여부에 따라 스케줄을 결정해서는 안됩니다. 속성이 평가된 시점과 해당 값을 사용하는 시점 간에 실제 대기 타스크 수가 변경될 수 있기 때문입니다.

대기 타스크의 존재 여부를 정확하게 확인하려면 조건부 입력 호출(또는 이에 해당하는 승인 구조)을 사용하십시오.

select
    The_Task.Some_Entry;
else
    -- do something else
end select;    

위의 예제가 다음 예제보다 바람직합니다.

if The_Task.Some_Entry'Count > 0 then
    The_Task.Some_Entry;
else
    -- do something else
end if;    

'Terminated 속성은 True 값을 나타내고 'Callable 속성은 False값을 나타내는 경우에만 의미가 있으므로 유용성에 한계가 있습니다. 이 두 속성은 시스템 종료 시 타스크 간에 동기화를 제공하기 위해 사용해서는 안됩니다.

손 모양 주의 아이콘우선순위 사용을 제한하십시오.

Ada의 우선순위는 스케줄에 제한적인 영향을 줍니다. 특히, 입력 대기열을 정렬하거나 선별적 대기를 수행할 입력을 선택할 때 입력을 대기하는 타스크의 우선순위를 고려하지 않습니다. 이러한 경우 우선순위가 반전되어([GOO88] 참조), 스케줄러는 실행 준비가 된 타스크에서 다음으로 실행할 타스크를 선택하는 데만 우선순위를 사용하게 됩니다. 이러한 우선순위 반전의 위험성으로 인해, 우선순위에 따라 상호 제외를 수행해서는 안됩니다.

입력 집합을 사용함으로써, 입력 대기열을 여러 시퀀스로 분할할 수 있으며 이를 통해 긴급 상황에 대한 명확한 개념을 이끌어낼 수 있습니다.

우선순위가 필요하지 않은 경우, 타스크에 우선순위를 지정하지 마십시오.

오케이 표시 아이콘하나의 타스크에 우선순위가 지정되면 응용프로그램의 모든 타스크에 우선순위를 지정하십시오.

프라그마(pragma) Priority가 없는 타스크 우선순위가 정의되지 않으므로 이 규칙이 필요합니다.

오케이 표시 아이콘이식성을 위해 우선순위 레벨 수를 적게 유지하십시오.

하위 유형 System.Priority의 범위는 구현으로 정의되며, 사용 가능한 실제 범위는 시스템에 따라 많이 다른 것으로 알려져 있습니다. 또한 우선순위를 중앙에서 정의함으로써, 모든 타스크에 정수 리터럴을 사용하는 대신 이름 및 정의를 부여할 수 있습니다. 이처럼 중앙 System_Priorities 패키지를 사용함으로써 이식성이 향상되며, 이전 규칙을 함께 적용하면 모든 타스크 스펙의 위치를 쉽게 파악할 수 있습니다.

검지 아이콘순환 타스크의 순서를 올바르게 지정하려면 다음과 같이 처리 시간, 오버헤드 및 우선 타스크를 고려하도록 delay 문을 프로그래밍하십시오.

Next_Time := Calendar.Clock;
loop
    -- Do the job.
    Next_Time := Next_Time + Period;
    delay Next_Time - Clock;
end loop;    

Next_Time - Clock은 순환 타스크가 늦게 실행됨을 나타내므로 부정적입니다. 경우에 따라 하나의 주기를 생략할 수도 있습니다.

검지 아이콘올바른 스케줄 지정을 위해 가장 자주 사용하는 타스크에 가장 높은 우선순위를 부여하는 Rate Monotonic Scheduling Algorithm에 따라 순환 타스크에 우선순위를 지정하십시오 (자세한 내용은 [SHA90] 참조).

검지 아이콘속도가 빠른 중개 서버(모니터, 버퍼)에 높은 우선순위를 지정하십시오.

그러나 이러한 경우 서버가 다른 타스크와 랑데뷰하여 스스로를 차단하지 않도록 해야 합니다. 프로그램 유지보수 과정에서 존중되도록 우선순위를 코드에 문서화하십시오.

검지 아이콘"지터" 영향을 최소화하려면 기간 자체가 아닌 시간 소인 입력 샘플 또는 출력 데이터에 의존하십시오.

오케이 표시 아이콘사용 중 대기(폴링)를 사용하지 마십시오.

수행할 작업을 확인하는 대신 타스크가 선택 또는 입력 호출을 사용하여 대기하거나 지연되는지 확인하십시오.

검지 아이콘각 랑데뷰에 대해, 최소한 한 측이 대기하고 한 측만 조건부 입력 호출이나 시간이 지정된 입력 호출 또는 대기를 갖도록 하십시오.

그렇지 않으면 특히 루프에서 코드가 경쟁 조건에 진입하여 사용 중 대기와 유사한 결과가 발생합니다. 우선순위를 잘못 사용하는 경우 결과가 더 악화될 수 있습니다.

검지 아이콘타스크를 캡슐화하는 경우, 일부 특수 특성을 명확히 표시해야 합니다.

입력 호출이 서브프로그램에서 숨겨져 있는 경우 해당 서브프로그램 스펙의 사용자에게 이 서브프로그램에 대한 호출이 차단될 수 있음을 알려야 합니다. 또한 대기 바인딩 여부를 지정하고, 이러한 경우 예상 상한을 제공해야 합니다. 이름 지정 규칙을 사용하여 잠재적 대기를 표시하십시오(위의 "서브프로그램" 섹션 참조).

패키지 정제, 서브프로그램 호출 또는 일반 유닛의 인스턴스화로 타스크가 활성화되는 경우, 이 사실을 다음과 같이 클라이언트에 알려야 합니다.

package Mailbox_Io is
    -- This package elaborates an internal Control task
    -- that synchronizes all access to the external 
    -- mailbox 
    procedure Read_Or_Wait
        (Name: Mailbox.Name; Mbox: in out Mailbox.Object);
        --
        -- Blocking (unbounded wait).    

오케이 표시 아이콘선별적 대기에서의 입력 선택을 위해 특정 순서에 의존하지 마십시오.

입력 대기열에 지정된 타스크를 공정하게 선택해야 하는 경우, 입력 대기가 없는 대기열을 원하는 순서대로 명시적으로 확인한 다음 모든 입력에서 대기하십시오. 'Count는 사용하지 마십시오.

오케이 표시 아이콘동일한 선언 파트에서의 타스크 정제를 위해 특정 활성화 순서에 의존하지 마십시오.

특정 시작 순서를 지정하려면 특수 시작 입력과의 랑데뷰를 작성해야 합니다.

오케이 표시 아이콘타스크가 정상적으로 종료되도록 구현하십시오.

타스크는 한 번 활성화되면 영구 실행되므로 응용프로그램의 속성에 해당 타스크가 필요하지 않은 경우, 정상 완료에 도달하거나 종료 대안을 통해 타스크를 종료해야 합니다. 마스터가 라이브러리 레벨 패키지인 타스크의 경우 이를 수행할 수 없습니다. Ada Reference Manual에서 종료 조건을 지정하지 않기 때문입니다.

마스터 종속 구조에서 정상 종료를 허용하지 않는 경우, 타스크는 특수 종료 입력을 제공하고 대기해야 합니다. 이 입력은 시스템 종료 시 호출됩니다.


11장

오류 처리 및 예외

일반적인 방법은 논리 및 프로그래밍 오류, 구성 오류, 손상된 데이터, 자원 부족 등 오류에만 예외를 사용하는 것입니다. 일반적인 규칙은 정상 조건과 오버로드 또는 하드웨어 실패가 없는 경우 예외가 발생하면 안된다는 것입니다.

검지 아이콘예외는 논리 및 프로그래밍 오류, 구성 오류, 손상된 데이터, 자원 부족을 처리하는데 사용하십시오. 예외는 발생 시점을 포함하여 가능한 빨리 적합한 로깅 메커니즘을 사용하여 보고하십시오.

검지 아이콘특정 추상에서 내보내는 예외 수를 최소화하십시오.

대규모 시스템의 경우, 각 레벨에서 여러 예외를 처리하도록 하면 코드를 읽고 유지보수하기가 어렵습니다. 이러한 경우 예외 처리가 정상 처리를 방해할 수 있습니다.

예외 수를 최소화하기 위한 몇 가지 방법은 다음과 같습니다.

오케이 표시 아이콘디자인에 지정되지 않은 예외를 전달하지 마십시오.

오케이 표시 아이콘발견한 예외가 다시 발생하지 않는 경우 예외 핸들러에서 when others 대안을 사용하지 마십시오.

이를 통해 이 레벨에서 처리할 수 없는 예외로 방해하지 않고 로컬 관리를 수행할 수 있습니다.

exception
    when others => 
        if Io.Is_Open (Local_File) then
            Io.Close (Local_File);
        end if;
        raise;
end;    

when others 대안을 사용할 수 있는 다른 위치는 타스크 본문의 맨 아래입니다.

오케이 표시 아이콘자주 발생하며 예상할 수 있는 이벤트에는 예외를 사용하지 마십시오.

명확한 오류가 아닌 조건을 나타내는데 예외를 사용하면 다음과 같은 몇 가지 불편사항이 발생합니다.

예를 들어, 함수에서 리턴되는 예비 값(예: 검색의 Value_Not_Found)의 양식으로 예외를 사용하지 마십시오. "out" 매개변수가 포함된 프로시저를 사용하거나 Not_Found를 의미하는 특수 값을 사용하거나 레코드의 리턴된 유형을 판별식 Not_Found로 압축하십시오.

오케이 표시 아이콘제어 구조를 구현하는데 예외를 사용하지 마십시오.

이는 예외를 "goto" 문의 양식으로 사용해서는 안된다는 이전 규칙의 특수한 경우입니다.

검지 아이콘사전 정의된 예외를 발견하는 경우, 해당 예외가 발생한 구조 주위의 작은 프레임 안에 핸들러를 배치하십시오.

Constraint_Error, Storage_Error 등과 같이 사전 정의된 예외는 여러 위치에서 발생할 수 있습니다. 특정 이유로 인해 이러한 예외 중 하나를 발견해야 하는 경우, 다음과 같이 핸들러의 범위를 제한해야 합니다.

begin
    Ptr := new Subscriber.Object;
exception
    when Storage_Error => 
        raise Subscriber.Collection_Overflow;
end;    

오케이 표시 아이콘함수에서 예외 핸들러를 종료하려면 "return" 문 또는 "raise" 문을 사용하십시오. 그렇지 않으면 호출자에서 Program_Error 예외가 발생합니다.

손 모양 주의 아이콘검사 억제를 제한하십시오.

오늘날의 Ada 컴파일러에서는 검사 억제에 따른 잠재적인 코드 크기 축소와 성능 향상 효과가 그다지 크지 않습니다. 따라서 검사 억제는 측정을 통해 성능 병목으로 식별된 소수의 코드로만 제한되며 전체 시스템에 적용되지 않습니다.

따라서 나중에 불특정 사용자가 검사 억제를 결정하는 있음직하지 않은 상황에 대비하기 위해 명시적인 범위 및 판별 검사를 추가하지 마십시오. Ada의 내장 제한조건 검사 기능에 의존하십시오.

검지 아이콘해당 선언 범위 밖의 예외를 전달하지 마십시오.

이러한 경우 클라이언트 코드로 예외를 명시적으로 처리할 수 없습니다. 단, when others 대안의 경우 구체적이지 않으므로 예외입니다.

이 규칙에 따라, 파생을 통해 유형을 다시 내보내는 경우 파생 서브프로그램으로 발생될 수 있는 예외를 다시 내보낼 수 있습니다(예: 이름 바꾸기). 그렇지 않은 경우, 클라이언트가 원래 정의 패키지에 "with"를 가져야 합니다.

검지 아이콘 Numeric_Error 및 Constraint_Error는 항상 함께 처리하십시오.

Ada 위원회에서는 Numeric_Error를 발생시킨 모든 상황에서 대신 Constraint_Error를 발생시키도록 결정했습니다.

검지 아이콘상태 코드의 값이 올바른지 확인하십시오.

서브프로그램에서 리턴한 상태 코드를 "out" 매개변수로 사용하는 경우, 항상 이 매개변수를 서브프로그램 본문의 첫 번째 실행 가능 명령문으로 작성하여 "out" 매개변수에 값을 지정하십시오. 체계적으로 모든 상태를 기본적으로 성공 또는 실패로 작성하십시오. 예외 핸들러를 포함하여 가능한 모든 서브프로그램 종료 방법을 고려하십시오.

검지 아이콘안전 점검은 로컬로 수행하십시오. 클라이언트가 이를 수행할 것으로 기대하지 마십시오.

즉, 올바른 입력이 제공되지 않아 서브프로그램에서 오류 출력이 생성되는 경우, 올바르지 않은 입력을 제어된 방식으로 감지하고 보고하는 코드를 서브프로그램에 설치하십시오. 클라이언트에게 올바른 값을 전달하도록 지시하는 주석에 의존하지 마십시오. 해당 주석은 곧 무시되고, 올바르지 않은 매개변수가 감지되지 않는 경우 디버그하기 어려운 오류가 발생합니다.

자세한 정보는 [KR90b]를 참조하십시오.


12장

하위 레벨 프로그래밍

이 섹션은 연역적으로 이식 불가능한 Ada 기능에 대해 설명합니다. 해당 기능은 Reference Manual for the Ada Programming Language [ISO87]의 13장에 정의되어 있으며 컴파일러 특정 기능은 Ada 컴파일러 벤더가 제공하는 "부록 F"에 설명되어 있습니다.

표시 절 및 속성

검지 아이콘 Ada Reference Manual의 부록 F를 학습하고 연습 코드를 작성하여 해당 내용을 잘 이해했는지 확인하십시오.

손 모양 주의 아이콘표시 절 사용을 제한하십시오.

표시 절은 구현에 따라 다르게 지원되고 사용 시 주의해야 할 점도 많이 있습니다. 따라서 시스템에서 마음대로 사용해서는 안됩니다.

표시 절의 기능을 다음과 같습니다.

다음과 같은 상황에서는 표시 절을 사용하지 않을 수 있습니다.

예제:

Replace:

type Foo is (Bla, Bli, Blu, Blo);
for Foo use (Bla => 1, Bli =>3, Blu => 4, Blo => 5);    

type Foo is (Invalid_0, Bla, Invalid_2, Bli, Blu, Blo);    

오케이 표시 아이콘구현 종속 코드를 포함한다고 명시적으로 식별된 패키지로 표시 절이 있는 유형을 그룹화하십시오.

오케이 표시 아이콘레코드 레이아웃에서 특정 순서를 가정하지 마십시오.

오케이 표시 아이콘레코드 표시 절에서, 항상 모든 판별식의 배치를 지정하되 변형에 컴포넌트를 지정하기 전에 수행하십시오.

오케이 표시 아이콘 alignment 절을 사용하지 마십시오.

컴파일러는 대상 맞추기 제한조건을 잘 알고 있으므로 제대로 작동할 것으로 신뢰해도 좋습니다. 프로그래머가 alignment 절을 사용하는 경우 나중에 맞추기 충돌이 발생할 수 있습니다.

검지 아이콘제약되지 않은 컴포지트 유형의 컴파일러 생성 필드가 있는지 확인하십시오.

레코드 내: 동적 필드의 오프셋, 변형 절 색인, 제약된 비트 등

배열 내: 도프 벡터

컴파일러에 대한 자세한 내용은 부록 F를 참조하십시오. Ada Reference Manual [ISO87]의 13장에 작성된 내용에 의존하지 마십시오.

Unchecked_Conversion

손 모양 주의 아이콘Unchecked_Conversion 사용을 제한하십시오.

Unchecked_Conversion에 대한 지원 정도는 Ada 컴파일러에 따라 큰 차이가 있으며, 특히 컴포지트 유형 및 액세스 유형과 관련된 정확한 동작에도 약간의 차이가 있습니다.

오케이 표시 아이콘 Unchecked_Conversion의 인스턴스화에 있어, 소스 및 대상 유형이 모두 제한적이며 크기가 같은지 확인하십시오.

이를 통해서만 제한적인 이식성을 얻을 수 있으며 도프 벡터와 같은 구현 추가 정보 관련 문제점을 피할 수 있습니다. 두 유형의 크기를 같게 만들기 위해서는 레코드 표시 절을 사용하여 두 유형을 레코드 유형에 "랩핑"해야 합니다.

제한된 유형을 만들려면 제한조건이 이미 계산된 "skin" 함수에서 인스턴스화를 수행해야 합니다.

검지 아이콘값 또는 타스크에 액세스하는데 Unchecked_Conversion을 사용하지 마십시오.

이는 Rational 원시 컴파일러와 같은 모든 시스템에서 지원되지 않습니다. 뿐만 아니라 다음 사항을 가정해서도 안됩니다.


13장

요약

다음은 유의해야 할 중요사항의 요약입니다.

제한 기능(손 모양 주의 아이콘):

금지 사항(검지 아이콘)


참조

이 문서의 내용은 Ada Guidelines: Recommendations for Designer and Programmers, Application Note #15, Rev. 1.1, Rational, Santa Clara, Ca., 1990. [KR90a]에서 가져온 것이지만 실제 정제를 위해서는 다양한 소스가 제공되었습니다.

BAR88 B. Bardin & Ch. Thompson, "Composable Ada Software Components and the Re-export Paradigm", Ada Letters, VIII, 1, Jan.-Feb. 1988, p.58-79.

BOO87 E. G. Booch, Software Components with Ada, Benjamin/Cummings (1987)

BOO91 Grady Booch: Object-Oriented Design with Applications, Benjamin-Cummings Pub. Co., Redwood City, California, 1991, 580p.

BRY87 D. Bryan, "Dear Ada," Ada Letters, 7, 1, January-February 1987, pp. 25-28.

COH86 N. H. Cohen, Ada as a Second Language, McGraw-Hill (1986), pp. 361-362.

EHR89 D. H. Ehrenfried, Tips for the Use of the Ada Language, Application Note #1, Rational, Santa Clara, Ca., 1987.

GAU89 M. Gauthier, Ada-Un Apprentissage, Dunod-Informatique, Paris (1989), pp. 368-370.

GOO88John B. Goodenough and Lui Sha: "The Priority Ceiling Protocol," special issue of Ada Letters, Vol., Fall 1988, pp. 20-31.

HIR92 M. Hirasuna, "Using Inheritance and Polymorphism with Ada in Government Sponsored Contracts", Ada Letters, XII, 2, March/April 1992, p.43-56.

ISO87 Reference Manual for the Ada Programming Language, International Standard ISO 8652:1987.

KR90a Ph. Kruchten, Ada Guidelines: Recommendations for Designer and Programmers, Application Note #15, Rev. 1.1, Rational, Santa Clara, Ca., 1990.

KR90b Ph. Kruchten, "Error-Handling in Large, Object-Based Ada Systems," Ada Letters, Vol. X, No. 7, (Sept. 1990), pp. 91-103.

MCO93 Steve McConnell, Code Complete-A Practical Handbook of Software Construction, Microsoft® Press, Redmond, WA, 1993, 857p.

MEN88 G. O. Mendal, "Three Reasons to Avoid the Use Clause," Ada Letters, 8, 1, January-February 1988, pp. 52-57.

PER88 E. Perez, "Simulating Inheritance with Ada", Ada letters, VIII, 5, Sept.-Oct. 1988, p. 37-46.

PLO92 E. Ploedereder, "How to program in Ada 9X, Using Ada 83", Ada Letters, XII, 6, November 1992, pp. 50-58.

RAC88 R. Racine, "Why the Use Clause Is Beneficial," Ada Letters, 8, 3, May-June 1988, pp. 123-127.

RAD85 T. P. Bowen, G. B. Wigle & J. T. Tsai, Specification of Software Quality Attributes, Boeing Aerospace Company, Rome Air Development Center, Technical Report RADC-TR-85-37 (3 volumes).

ROS87 J. P. Rosen, "In Defense of the Use Clause," Ada Letters, 7, 7, November-December 1987, pp. 77-81.

SEI72 E. Seidewitz, "Object-Oriented Programming with Mixins in Ada", Ada Letters, XII, 2, March/April 1992, p.57-61.

SHA90 Lui Sha and John B. Goodenough: "Real-Time Scheduling Theory and Ada," Computer, Vol. 23, #4 (April 1990), pp. 53-62.)

SPC89 Software Productivity Consortium: Ada Quality and Style-Guidelines for the Professional Programmer, Van Nostrand Reinhold (1989)

TAY92 W. Taylor, Ada 9X Compatibility Guide, Version 0.4, Transition Technology Ltd., Cwmbran, Gwent, U.K., Nov. 1992.

WIC89 B. Wichman: Insecurities in the Ada Programming Language, Report DITC137/89, National Physical Laboratory (UK), January 1989.


용어집

이 문서에서 사용하는 대부분의 용어는 Reference Manual for the Ada Programming Language, [ISO87]의 부록 D에 정의되어 있습니다. 추가 용어에 대한 정의는 다음과 같습니다.

ADL: 디자인 언어로서의 Ada로서, Ada를 사용하여 디자인 측면을 표현하는 방법을 나타냅니다(즉, PDL 또는 프로그램 디자인 언어).

환경: 사용 중인 Ada 소프트웨어 개발 환경

라이브러리 전환: Rational 환경에서, 전체 프로그램 라이브러리에 적용되는 컴파일 옵션

모델 환경: Rational Environment환경에서, 일관된 프로젝트 전체 라이브러리 전환 설정을 캡처하는 데 사용되는 특수 라이브러리

가변: 판별식이 기본값을 갖는 레코드의 특성. 가변 유형의 오브젝트에는 임의의 유형 값이 지정될 수 있습니다. 이러한 값에는 해당 판별식과 결과적으로 해당 구조까지 변경하는 값도 포함됩니다.

스킨: 본문이 릴레이 기능만 수행하는 서브프로그램으로서, 하나의 명령문 세트(동일한 매개변수 세트 또는 상호 변환 가능한 매개변수를 사용한 다른 서브프로그램에 대한 호출)만 포함하는 것이 바람직합니다.

PDL: 프로그램 디자인 언어