이 문서는 주로 Delphi 개발자에게 소스 코드 작성 표준은 물론 프로그램과 파일의 명명 표준을 제공하여 프로그래밍 시 따라야 할 일관된 형식을 가질 수 있도록 하기 위한 것입니다. 이런 방식으로 각 프로그래머는 다른 사람이 이해할 수 있는 코드를 작성합니다.
들여쓰기는 각 레벨 사이에 두 개의 공백을 의미합니다. 소스 코드에 탭 문자를 넣지 마세요. 이는 탭 문자의 너비가 설정 및 코드 관리 유틸리티(인쇄, 문서, 버전 제어 등)에 따라 다르기 때문입니다.
도구|환경 메뉴를 사용하여 환경 옵션 대화 상자의 일반 페이지에서 탭 문자 사용 및 선택적 채우기 확인란을 선택 취소하여 탭 문자가 저장되지 않도록 합니다.
여백은 80자로 설정됩니다. 소스 코드는 일반적으로 단어를 써서 여백을 초과하지 않지만 이 규칙이 더 유연합니다. 가능하면 한 줄보다 긴 명령문은 쉼표나 연산자로 묶어야 합니다. 줄 바꿈 후에는 두 문자씩 들여쓰기해야 합니다.
시작 문은 한 줄에 단독으로 있어야 합니다. 예를 들어, 아래 첫 번째 줄은 올바르지 않지만 두 번째 줄은 정확합니다.
for i:=0 to 10 do start // 틀렸습니다. start와 for는 같은 줄에 있습니다.
for i:=0 to 10 do // 예, 다른 줄에서 시작하세요
시작하다
이 규칙의 특별한 경우는 시작이 else 문의 일부인 경우입니다. 예를 들면 다음과 같습니다.
어떤 진술 = 그렇다면
시작하다
.
끝
그렇지 않으면 시작하다
기타 진술;
끝;
참고: end 문은 항상 별도의 줄에 있습니다. start가 else 문의 일부가 아닌 경우 해당 end 문은 start 문과 동일한 양만큼 들여쓰기됩니다.
일반적으로 "{...}" 유형의 블록 주석을 사용합니다. 이전의 "(*...*)" 유형 블록 주석은 사용되지 않는 코드를 일시적으로 주석 처리하는 데 사용됩니다. Line. 주석, Delphi 2.0 미만 버전을 지원하지 않기로 결정한 경우 "//" 주석을 사용할 수 있습니다.
여는 괄호와 다음 문자 사이에는 공백이 없습니다. 마찬가지로 닫는 괄호와 이전 문자 사이에는 공백이 없습니다. 다음 예에서는 올바른 공백과 잘못된 공백을 보여줍니다.
CallPROc( 매개변수 ); // 오류!
CallProc(Aparameter); // 맞습니다!
명령문에 추가 괄호를 포함하지 마십시오. 소스 코드에서 괄호는 꼭 필요한 경우에만 사용됩니다. 다음 예에서는 올바른 사용법과 잘못된 사용법을 보여줍니다.
if (I=42) then // 오류, 괄호가 중복되었습니다.
if (I=42) or (J=42) then // 정답입니다. 대괄호를 사용해야 합니다.
오브젝트 파스칼 언어의 예약어와 키워드는 항상 모두 소문자입니다. 다음은 Delphi 5 예약어 목록입니다.
그리고 | 정렬 | ~처럼 | asm |
시작하다 | 사례 | 수업 | const |
건설자 | 오물 소각로 | 디스인터페이스 | div |
하다 | 아래로 | 또 다른 | 끝 |
제외하고 | 수출 | 파일 | 마무리 |
마지막으로 | ~을 위한 | 기능 | 고토 |
만약에 | 구현 | ~에 | 물려받은 |
초기화 | 인라인 | 인터페이스 | ~이다 |
상표 | 도서관 | 모드 | 무 |
~ 아니다 | 물체 | ~의 | 또는 |
밖으로 | 포장된 | 절차 | 프로그램 |
재산 | 들어올리다 | 기록 | 반복하다 |
자원 문자열 | 세트 | shl | 쉬르 |
끈 | 그 다음에 | threadvar | 에게 |
노력하다 | 유형 | 단위 | ~까지 |
용도 | var | ~하는 동안 | ~와 함께 |
xor | 사적인 | 보호됨 | 공공의 |
출판됨 | 자동화된 |
프로시저 이름은 대문자로 시작해야 하며 가독성을 높이기 위해 시차를 두어야 합니다. 다음은 잘못된 작성 방법입니다.
이 절차는 형식이 잘못된 루틴 이름입니다.
다음과 같이 변경하세요.
프로시저 ThisIsMuchMoreReadableRoutineName;
가능하면 동일한 유형의 매개변수를 함께 그룹화해야 합니다.
절차 Foo(Param1,Param2,Param3:Imteger;Param4:string);
형식 매개변수의 순서는 주로 레지스터 호출 규칙에 따라 달라집니다. 가장 일반적으로 사용되는 매개변수는 첫 번째 매개변수이며 사용 빈도 순으로 왼쪽에서 오른쪽으로 정렬됩니다. 입력 매개변수는 출력 매개변수보다 우선합니다. 범위가 큰 매개변수는 범위가 작은 매개변수 앞에 배치되어야 합니다. 예를 들어:
SomeProc(aPlanet, aContinent, aCountry, aState, aCity).
일부는 예외입니다. 예를 들어, 이벤트 처리 중에 TObject 유형의 Sender 매개변수가 전달되는 첫 번째 매개변수인 경우가 많습니다.
레코드, 배열, 짧은 문자열 또는 인터페이스 유형의 매개변수가 프로시저에 의해 수정되는 것을 방지하려면 형식 매개변수를 Const로 표시해야 합니다. 이러한 방식으로 컴파일러는 가장 효율적인 방식으로 코드를 생성하여 전달된 매개변수가 변경되지 않도록 보장합니다.
다른 유형의 매개변수가 프로시저에 의해 수정되지 않을 것으로 예상되는 경우 Const로 표시할 수도 있습니다. 이는 효율성에 영향을 주지 않지만 프로시저 호출자에게 더 많은 정보를 제공합니다.
지역 변수는 프로시저 내에서 사용됩니다. 필요한 경우 프로시저 시작 시 즉시 변수를 초기화해야 합니다. 로컬 AnsiString 유형 변수는 자동으로 빈 문자열로 초기화되고, 로컬 인터페이스 및 dispinterface 유형 변수는 자동으로 nil로 초기화되며, 로컬 Variant 및 OleVariant 유형 변수는 자동으로 할당되지 않음으로 초기화됩니다.
전역 변수의 사용은 일반적으로 권장되지 않습니다. 그러나 때로는 필요할 때도 있습니다. 그렇더라도 전역 변수는 필요한 환경으로 제한되어야 합니다. 예를 들어, 전역 변수는 해당 유닛의 구현 부분에만 전역적일 수 있습니다.
여러 유닛에서 사용할 글로벌 데이터를 공통 유닛으로 옮겨 모든 개체에서 사용해야 합니다. 전역 데이터는 선언 시 값으로 직접 초기화될 수 있습니다. 모든 전역 변수는 자동으로 0으로 초기화되므로 전역 변수를 0, nil, Unsigned 등의 null 값으로 초기화하지 마십시오. 0으로 초기화된 전역 변수는 .EXE 파일에서 공간을 차지하지 않습니다. 0으로 초기화된 데이터는 가상 데이터 세그먼트에 저장되며, 가상 데이터 세그먼트는 애플리케이션이 시작될 때만 메모리를 할당합니다. 0이 아닌 초기화된 전역 데이터는 .EXE 파일에서 공간을 차지합니다.
유형 식별자는 예약어이므로 모두 소문자여야 합니다. Win32 API 유형은 모두 대문자로 표시되는 경우가 많으며 Windows.pas 또는 기타 API 단위와 같은 특정 유형 이름에 대한 규칙을 따릅니다. 기타 변수명의 경우 첫 글자는 대문자로, 나머지 글자는 대소문자를 번갈아 표기해야 합니다. 다음은 몇 가지 예입니다.
var
MyString: 문자열; // 예약어
WindowsHandle: HWND; // Win32 API 유형
I: 정수; //시스템 유닛에 도입된 유형 식별자
Real 유형은 이전 Pascal 코드와의 호환성을 위해서만 예약되어 있으므로 사용하지 않는 것이 좋습니다. 일반적으로 부동 소수점 숫자에는 Double을 사용해야 합니다. Double은 프로세서에 의해 최적화될 수 있으며 IEEE에서 정의한 표준 데이터 형식입니다. Extend는 Double이 제공하는 것보다 더 큰 범위가 필요할 때 사용할 수 있습니다. 확장은 Intel 특정 유형이며 Java에서는 지원되지 않습니다. 부동 소수점 변수의 물리적 바이트 수가 중요한 경우(다른 언어를 사용하여 DLL을 작성하는 경우) Single을 사용해야 합니다.
일반적으로 Variant 및 OleVariant를 사용하지 않는 것이 좋습니다. 그러나 이 두 가지 유형은 데이터 유형이 런타임에만 알려진 경우(종종 COM 및 데이터베이스 응용 프로그램에서) 프로그래밍에 필요합니다. ActiveX 컨트롤 자동화와 같은 COM 프로그래밍을 수행할 때는 COM이 아닌 프로그래밍에는 OleVariant를 사용해야 하며 Variant를 사용해야 합니다. 이는 Variant가 Delphi의 기본 문자열을 효과적으로 저장할 수 있는 반면 OleVariant는 모든 문자열을 OLE 문자열(예: WideChar 문자열)로 변환하고 참조 계산 기능이 없기 때문입니다.
if/then/else 문에서 실행 가능성이 가장 높은 경우는 then 절에 배치하고 가능성이 낮은 경우는 else 절에 배치해야 합니다. 많은 if 문을 피하려면 대신 Case 문을 사용하세요. 레벨이 5개보다 많으면 if 문을 사용하지 마세요. 대신 더 명확한 방법을 사용하십시오. if 문에 추가 괄호를 사용하지 마세요.
if 문에 테스트할 조건이 여러 개 있는 경우 계산 복잡도에 따라 오른쪽에서 왼쪽으로 정렬해야 합니다. 이를 통해 코드는 컴파일러의 단락 추정 논리를 최대한 활용할 수 있습니다. 예를 들어 Condition1이 Condition2보다 빠르고 Condition2가 Condition3보다 빠른 경우 if 문은 일반적으로 다음과 같이 구성되어야 합니다.
조건1, 조건2, 조건3인 경우
조건3이 거짓일 가능성이 높은 경우 단락 추정 논리를 사용하여 조건3을 앞에 배치할 수도 있습니다.
조건3, 조건1, 조건2인 경우
Case문의 각 Case에 대한 상수는 숫자순이나 알파벳순으로 배열되어야 합니다. 각 상황에 대한 작업 설명은 짧아야 하며 일반적으로 4~5줄의 코드를 넘지 않아야 합니다. 작업이 너무 복잡하면 코드를 별도의 프로시저나 함수에 배치해야 합니다. Case 문의 else 절은 기본 사례 또는 오류 감지에만 사용됩니다.
Case 문은 일반적인 들여쓰기 및 명명 규칙을 따릅니다.
while 루프를 종료하기 위해 Exit 프로시저를 사용하지 않는 것이 좋습니다. 필요한 경우 루프 조건을 사용하여 루프를 종료해야 합니다. while 루프를 초기화하는 모든 코드는 while 항목 앞에 위치해야 하며 관련 없는 문으로 구분되어서는 안 됩니다. 업무를 위한 모든 보조 작업은 주기 직후에 수행되어야 합니다.
루프 횟수가 결정되면 while 문 대신 for 문을 사용해야 합니다.
반복 문은 while 루프와 유사하며 동일한 규칙을 따릅니다.
with 문은 주의해서 사용해야 합니다. 특히 with 문 내에서 여러 개체나 레코드를 사용할 때 with 문을 과도하게 사용하지 마세요. 예를 들어:
Record1, Record2를 사용하면
이러한 상황은 프로그래머를 쉽게 혼란스럽게 하고 디버깅을 어렵게 만들 수 있습니다.
with 문은 이름 지정 및 들여쓰기에 대한 이 장의 규칙도 따릅니다.
예외 처리는 주로 오류를 수정하고 리소스를 보호하는 데 사용됩니다. 즉, 리소스가 할당될 때마다 try...finally를 사용하여 리소스가 해제되었는지 확인해야 합니다. 다만, 유닛의 초기/마지막 부분이나 객체의 생성자/소멸자에서 리소스를 할당/해제하는 경우는 예외로 합니다.
가능한 경우 각 리소스 할당은 try...finally 구조와 일치해야 합니다. 예를 들어 다음 코드는 오류를 일으킬 수 있습니다.
SomeClass1 := TSomeClass.Create;
SomeClass2 := TSomeClass.Create;
노력하다
{ 코드를 작성하세요 }
마지막으로
SomeClass1.Free;
SomeClass2.Free;
끝;
위의 리소스 할당에 대한 안전한 솔루션은 다음과 같습니다.
SomeClass1 := TSomeClass.Create;
노력하다
SomeClass2 := TSomeClass.Create;
노력하다
{ 코드를 작성하세요 }
마지막으로
SomeClass2.Free;
끝;
마지막으로
SomeClass1.Free;
끝;
예외가 발생할 때 일부 작업을 수행하려면 try...Exception을 사용할 수 있습니다. 일반적으로 단순히 오류 메시지를 표시하는 경우를 제외하고는 try...를 사용할 필요가 없습니다. 응용 프로그램 개체가 컨텍스트에 따라 자동으로 이 작업을 수행할 수 있기 때문입니다. 절에서 기본 예외 처리를 활성화하려면 예외를 다시 트리거할 수 있습니다.
else 절과 함께 try...Exception을 사용하는 것은 권장되지 않습니다. 이렇게 하면 처리할 준비가 되지 않은 예외를 포함하여 모든 예외가 차단되기 때문입니다.
프로시저와 함수 이름은 의미가 있어야 합니다. 작업을 수행하는 과정의 이름 앞에는 작업을 표현하는 동사를 붙이는 것이 가장 좋습니다. 예를 들어:
절차 FormatHardDrive;
입력 매개변수 값을 설정하는 절차의 이름에는 Set이라는 접두어가 붙어야 합니다. 예를 들면 다음과 같습니다.
절차 SetUserName;
값을 얻기 위한 프로시저의 이름에는 Get이라는 접두사가 붙어야 합니다. 예를 들면 다음과 같습니다.
함수 GetUserName:문자열;
모든 형식 매개변수의 이름은 그 목적을 표현해야 합니다. 적절한 경우, 형식 매개변수의 이름에는 문자 a가 접두어로 붙는 것이 바람직합니다. 예를 들면 다음과 같습니다.
프로시저 SomeProc(aUserName:string; aUserAge:integer);
매개변수 이름이 클래스 속성 또는 필드와 동일한 이름을 갖는 경우 접두사 a가 필요합니다.
두 유닛에 동일한 이름의 프로시저가 포함된 경우 프로시저가 호출되면 나중에 Uses 절에 나타나는 유닛의 프로시저가 실제로 호출됩니다. 이를 방지하려면 메소드 이름 앞에 원하는 단위 이름을 추가하십시오. 예를 들면 다음과 같습니다.
SysUtils.FindClose(SR);
또는 Windows.FindClose(Handle);
변수 이름은 그 목적을 표현해야 합니다. 루프 제어 변수는 I, J, K와 같은 단일 문자인 경우가 많습니다. UserIndex와 같이 보다 의미 있는 이름을 사용할 수도 있습니다. 부울 변수 이름은 True 및 False 값의 의미를 명확하게 나타내야 합니다.
지역 변수는 다른 변수의 명명 규칙을 따릅니다.
전역 변수는 대문자 "G"로 시작하고 다른 변수의 명명 규칙을 따릅니다.
열거 유형 이름은 열거의 목적을 나타내야 합니다. 데이터 유형임을 나타내기 위해 이름 앞에 T 문자가 앞에 와야 합니다. 열거형 식별자 목록의 접두사는 서로 연관될 2~3개의 소문자를 포함해야 합니다. 예를 들어:
TSongType=(stRock, stClassical, stCountry, stAlternative, stHeavyMetal, stRB);
열거 유형의 변수 인스턴스 이름은 유형과 동일하지만 접두사 T가 없습니다. 변수에 FavoriteSongTypel, FavoriteSongType2 등과 같이 보다 특별한 이름을 지정할 수도 있습니다.
배열 유형 이름은 배열의 목적을 표현해야 합니다. 유형 이름 앞에는 문자 "T"가 붙어야 합니다. 배열 유형에 대한 포인터를 선언하려면 포인터 앞에 문자 P를 붙이고 유형 선언 앞에 선언해야 합니다. 예를 들어:
유형
PCycleArray = ^TCycleArray;
TCycleArray=정수 배열[1..100];
실제로 배열 유형의 변수 인스턴스는 유형과 이름이 동일하지만 "T" 접두사가 없습니다.
레코드 유형 이름은 레코드의 목적을 표현해야 합니다. 유형 이름 앞에는 문자 T가 붙어야 합니다. 레코드 유형에 대한 포인터를 선언하려면 포인터 앞에 문자 P를 붙이고 유형 선언 앞에 선언해야 합니다. 예를 들어:
유형
PEmployee = ^TEmployee;
Temployee=기록
직원 이름: 문자열;
직원 비율: 두 배;
끝;
클래스 이름은 클래스의 목적을 표현해야 합니다. 일반적으로 클래스 이름 앞에 문자 "T"를 추가해야 하며, 인터페이스 클래스인 경우에는 클래스 이름 앞에 "I"를 추가해야 하며, 오류 예외 클래스의 클래스 이름에는 "E"를 추가해야 합니다. 클래스 이름 앞에 클래스 참조 유형(클래스 참조 유형)을 추가해야 합니다. 이름 뒤에 "클래스"를 추가하세요. 예를 들어:
유형
TCustomer = 클래스(TObject);
ICustomer = 인터페이스;
TCustomerClass = TCustomer 클래스
ECustomerException = 클래스(예외);
클래스의 인스턴스 이름은 일반적으로 접두사 "T"를 제외하고 클래스 이름과 동일합니다.
var
고객: T고객;
참고: 구성요소의 이름은 "구성요소 유형"을 참조하십시오.
필드 이름 지정은 필드임을 나타내기 위해 접두사 F가 추가된다는 점을 제외하면 변수와 동일한 규칙을 따릅니다.
모든 필드는 비공개여야 합니다. 클래스 범위 밖의 필드에 액세스하려면 클래스 속성을 사용하면 됩니다.
이름 지정 방법은 프로시저 및 함수와 동일한 규칙을 따릅니다.
파생 클래스가 메서드를 재정의하지 않으려면 정적 메서드를 사용해야 합니다.
파생 클래스로 메서드를 재정의하려면 가상 메서드를 사용해야 합니다. 클래스 메서드를 여러 파생 클래스에서 직접 또는 간접적으로 사용하려면 동적 메서드(동적)를 사용해야 합니다. 예를 들어, 클래스에 자주 재정의되는 메서드가 포함되어 있고 100개의 파생 클래스가 있는 경우 메서드를 동적으로 정의해야 메모리 오버헤드를 줄일 수 있습니다.
클래스가 인스턴스를 생성하려는 경우 추상 메서드를 사용하지 마세요. 추상 메서드는 인스턴스를 생성하지 않는 기본 클래스에서만 사용할 수 있습니다.
모든 속성 액세스 메서드는 클래스의 private 또는 protected 부분에서 정의되어야 합니다. 속성 액세스 방법은 프로시저 및 함수와 동일한 규칙을 따릅니다. 읽기에 사용되는 메서드에는 "Get"이라는 접두사가 붙어야 하고, 쓰기에 사용되는 메서드에는 "Set"이라는 접두사가 붙어야 하며, 속성 유형과 동일한 유형의 Value라는 매개 변수가 있어야 합니다. 예를 들어:
TSomeClass = 클래스(TObject)
사적인
fsomeField: 정수;
보호됨
함수 GetSomeField: 정수;
절차 SetSomeField(값: 정수);
공공의
속성 SomeField: 정수 읽기 GetSomeField 쓰기 SetSomeField;
끝;
필수는 아니지만 쓰기 액세스 방법을 사용하여 전용 필드를 나타내는 속성에 액세스하는 것이 좋습니다.
속성은 비공개 필드에 대한 접근자 역할을 하며 F 접두사가 없는 경우를 제외하고 필드와 동일한 명명 규칙을 따릅니다. 속성 이름은 동사가 아닌 명사여야 합니다. 속성은 데이터이고 메서드는 작업입니다. 배열 속성 이름은 복수형이어야 하고, 일반 속성은 단수형이어야 합니다.
구성 요소 이름 지정은 다른 구성 요소 이름과 충돌하는 경우 회사, 개인 또는 기타 엔터티를 식별하기 위해 3자 접두사를 추가할 수 있다는 점을 제외하면 클래스 이름 지정과 유사합니다. 예를 들어 시계 구성 요소는 다음과 같이 선언될 수 있습니다.
TddgClock = 클래스(TComponent)
접두사의 세 문자는 소문자여야 합니다.
구성 요소 인스턴스의 이름은 실제 의미를 설명할 수 있어야 합니다. 여기서 명명 규칙은 수정된 헝가리어 접두사 명명 규칙을 사용합니다. 접미사 대신 접두사를 사용하는 이유는 컴포넌트의 유형을 검색하는 것보다 Object Inspector 및 Code Explorer에서 컴포넌트 이름을 검색하는 것이 더 쉽기 때문입니다. 이 표준에서 구성 요소 인스턴스 이름은 접두사와 속성 식별자라는 두 부분으로 구성됩니다.
구성 요소의 접두사는 대부분 구성 요소 유형의 약어입니다. 아래 표에서 구성 요소 접두사를 참조하세요.
구성요소 클래스 이름 | 구성 요소 접두어 |
TActionList, TAction은 액션의 목록 항목을 나타냅니다. | 행동 |
TButton, TSpeedButton, TBitBtn 및 기타 버튼 클래스 | btn |
TCheckBox, TDBCheckBox 및 기타 확인란 | chk |
TRadioButton 라디오 버튼 클래스 | 르도 |
TToolBar 도구 모음 | 결핵 |
TMainMenu의 모든 메인 메뉴 클래스 | mm |
TMainMenuItem의 모든 메뉴 항목 클래스 | 미 |
TPopupMenu의 모든 팝업 메뉴 클래스 | 오후 |
TPopupMenuItem의 모든 팝업 메뉴 항목 클래스 | 피미 |
표시에 사용되는 TLabel, TStaticText 및 기타 레이블 클래스 | lbl |
TPanel 및 기타 패널 클래스 | nnl |
TPageControl 및 기타 페이지 제어 클래스 | pgc |
TEdit, TMaskEdit 및 기타 한 줄 편집 상자 클래스 | edt |
TMemo, TRichEdit 및 기타 여러 줄 편집 상자 클래스 | mmo |
TDrawGrid, TStringGrid 및 기타 그리드 클래스 | grd |
TAnimate 및 기타 애니메이션 클래스 | 애니 |
TImageList 및 기타 이미지 목록 클래스 | 일 |
TImage 및 기타 이미지 클래스 | img |
TChart 차트 클래스 | cht |
TComboBox, TDBComboBox 및 기타 드롭다운 목록 상자 클래스 | CBO |
TListBox, TDBList 및 기타 목록 상자 클래스 | 첫 번째 |
TTreeView | TV |
TListView | lv |
T핫키 | 홍콩 |
TSplitter 및 기타 구분자 클래스 | spt |
TOpenDialog와 같은 모든 대화 상자 구성 요소 클래스 | dlg |
TTable과 같은 모든 데이터 테이블 클래스 | tbl |
TQuery와 같은 모든 SQL 쿼리 구성 요소 | 큐리 |
TClientDataSet의 모든 클라이언트 데이터 세트 요소 | CD |
TDataSource | DS |
T데이터베이스 | 디비 |
TSockConnection, TDCOMConnection 및 기타 연결 구성 요소 클래스 | 범죄자 |
TQuickRep, TFastReport 및 기타 보고서 구성 요소 클래스 | rpt |
TDDEClientConv, TDDEClientItem 및 기타 DDE 구성 요소 클래스 | ㅋㅋㅋ |
TMonthCalendar와 같은 모든 캘린더 클래스 | 칼 |
TGroupBox 및 기타 컨트롤 클래스 | grp |
위에 표시된 대로 구성 요소 유형 접두사는 구성 요소를 설명하는 유형 속성을 분석하여 생성됩니다. 일반적으로 다음 규칙은 구성요소 유형 접두어를 정의하는 방법을 설명합니다.
참고: 구성 요소의 접두사는 버튼, 라벨 등 구성 요소의 유형을 나타내는 것이므로 각 특수 구성 요소 클래스에 대해 구성 요소 접두사를 만들 필요가 없습니다. TMyButton은 여전히 btn입니다.
구성 요소 속성 식별 이름은 구성 요소의 의도에 대한 설명입니다. 예를 들어, 양식을 닫는 데 사용되는 TButton 구성 요소 인스턴스의 이름은 btnClose로 지정할 수 있습니다. 이름 편집 구성 요소의 인스턴스 이름은 edName으로 지정될 수 있습니다.
양식 또는 대화 상자 유형의 이름은 양식의 경우 "Tfrm" 접두어, 대화 상자의 경우 "Tdlg"라는 접두어가 붙고 그 뒤에 설명적인 이름이 따라오는 양식의 목적을 표현해야 합니다. 예를 들어 정보 양식 유형 이름은 다음과 같습니다.
TfrmAbout = 클래스(TForm)
기본 양식의 유형 이름은 다음과 같습니다.
TfrmMain = 클래스(TForm)
고객 로그인 양식의 유형 이름은 다음과 같습니다.
TfrmCustomerEntry = 클래스(TForm)
로그인 대화 상자의 유형 이름은 다음과 같습니다.
TdlgLogin = 클래스(TForm)
양식 인스턴스의 이름은 해당 유형 이름과 동일하지만 접두사 T가 없습니다. 예를 들어 앞서 언급한 양식 유형 및 인스턴스의 이름은 다음과 같습니다.
이름을 입력하세요 | 인스턴스 이름 |
Tfrm정보 | frm정보 |
Tfrm메인 | 메인 |
Tfrm고객 항목 | frmCustomerEntry |
Tdlg로그인 | dlg로그인 |
특별한 이유가 없는 한 기본 폼만 자동 생성됩니다. 다른 모든 양식은 프로젝트 옵션 대화 상자의 자동 생성 목록에서 제거되어야 합니다. 자세한 내용은 다음 섹션을 참조하세요.
모든 양식 단위에는 양식 작성, 설정, 모달 표시 및 릴리스를 위한 인스턴스화 기능이 포함되어야 합니다. 이 함수는 양식에서 반환된 모드 결과를 반환합니다. 이 함수에 전달된 매개변수는 매개변수 전달 규칙을 따릅니다. 이와 같이 캡슐화하는 이유는 코드 재사용 및 유지 관리를 용이하게 하기 위한 것입니다.
폼의 변수는 유닛에서 제거되고 폼 인스턴스화 기능에서 로컬 변수로 정의되어야 합니다. (이렇게 하려면 프로젝트 옵션 대화 상자의 자동 생성 목록에서 폼을 제거해야 합니다. 이전 내용을 참조하십시오.
예를 들어, 다음 유닛 파일은 GetUserData 인스턴스화 기능을 보여줍니다.
단위 UserDataFrm;
인터페이스
용도
Windows, 메시지, SysUtils, 클래스, 그래픽, 컨트롤, 양식,
대화 상자, StdCtrls;
유형
TfrmUserData = 클래스(TForm)
edtUserName: TEdit;
edtUserID: TEdit;
사적인
{비공개 선언}
공공의
{공개 선언}
끝;
function GetUserData(var aUserName: String;var aUserID: Integer): Word;
구현
{$R *.DFM}
function GetUserData(var aUserName: String;var aUserID: Integer): Word;
var
frmUserData: TfrmUserData;
시작하다
frmUserData := TfrmUserData.Create(응용 프로그램);
frmUserData.Caption:='사용자 데이터 가져오기';
결과 : = frmUserData.ShowModal;
결과=mrOK이면
시작하다
aUserName := frmUserData.edtUserName.Text;
aUserID := StrToInt(frmUserData.edtUserID.Text);
끝;
마지막으로
frmUserData.Free;
끝;
끝;
끝.
양식 구조가 너무 복잡하면 기본 양식 프레임과 기본 양식 프레임에 포함된 여러 하위 양식 프레임으로 나누어야 합니다. 좋다:
TfrmMainFrame: TfrmInfoFrame,TfrmEditorFrame
폼 프레임을 사용하는 주요 목적은 인터페이스 및 코드 재사용 문제를 해결하고, 단위 코드의 응집력을 향상시켜(분할 후 각 폼 프레임은 독립적인 단위임) 소프트웨어 엔지니어링의 품질을 향상시키는 것입니다. 인터페이스 관련 코드(재사용 가능)와 애플리케이션 관련 코드(재사용 불가능)를 추출해야 합니다.
데이터 모듈 유형 이름은 해당 목적을 표현해야 하며 "Tdm"이라는 접두사와 설명적인 이름이 뒤에 와야 합니다. 예를 들어 고객 데이터 모듈의 유형 이름은 다음과 같습니다.
TdmCustomer = 클래스(TDataModule)
Orders 데이터 모듈의 유형 이름은 다음과 같습니다.
TdmOrder = 클래스(TDataModule)
데이터 모듈 인스턴스의 이름은 해당 유형 이름과 동일해야 하지만 T 접두사는 없어야 합니다. 예를 들어 이전 데이터 모듈 유형과 인스턴스 이름은 다음과 같습니다.
이름을 입력하세요 | 인스턴스 이름 |
Tdm고객 | dm고객 |
Tdm주문 | dm주문 |
모든 소스 파일, 프로젝트 파일, 유닛 파일에는 구조화된 파일 헤더 정보를 사용하는 것이 좋습니다. 파일 헤더에는 최소한 다음 정보가 포함되어야 합니다.
{
저작권 @ 저자별 연도
}
프로젝트 파일 이름은 설명적이어야 합니다. 예를 들어, "The Delphi 5 Developer's Guide Bug Manager"의 프로젝트 이름은 DDGBugs.dpr이고, 시스템 정보 프로그램의 이름은 SysInfo.dpr입니다.
양식 파일의 이름은 양식의 목적을 표현해야 하며 접미사 Frm을 가져야 합니다. 예를 들어 About 양식의 파일 이름은 AboutFrm.dfm이고 기본 양식의 파일 이름은 MainFrm.dfm입니다.
데이터 모듈 파일 이름은 데이터 모듈의 역할을 표현해야 하며 DM 접미사를 붙여야 합니다. 예를 들어, Customers 데이터 모듈의 파일 이름은 CustomersDM.dfm입니다.
원격 데이터 모듈 파일의 이름은 원격 데이터 모듈의 목적을 표현해야 합니다. 이름 뒤에 RDM 접미사를 추가합니다. 예를 들어, Customers 원격 데이터 모듈용 파일은 CustomersRDM.dfm입니다.
단위 이름은 설명적이어야 합니다. 예를 들어 애플리케이션의 기본 양식 단위는 MaimFrm.pas입니다.
인터페이스 섹션의 사용 절에는 해당 섹션에 필요한 단위만 포함되어야 합니다. Delphi에서 자동으로 추가할 수 있는 단위 이름을 포함하지 마십시오. 구현 부분의 사용 절에는 이 부분에 필요한 단위만 포함되어야 하며 추가 단위는 포함되어서는 안 됩니다.
인터페이스 섹션에는 외부 장치에서 액세스해야 하는 유형, 변수, 프로시저 및 함수의 선언만 포함되어야 합니다. 또한 이러한 선언은 구현 섹션보다 앞에 있어야 합니다.
구현 부분에는 이 유닛의 개인 유형, 변수, 프로시저 및 기능의 구현이 포함됩니다.
초기화 섹션에 시간이 많이 걸리는 코드를 배치하지 마십시오. 그렇지 않으면 응용 프로그램이 매우 느리게 시작됩니다.
초기화 섹션에서 할당된 모든 리소스를 해제해야 합니다.
양식 단위 파일의 이름은 해당 양식 이름과 동일하며 접두어를 접미어로 변경하면 됩니다. 예를 들어 About 양식의 단위 이름은 AboutFrm.pas입니다. 메인 폼의 단위 파일명은 MainFrm.pas입니다.
데이터 모듈 단위 파일의 이름은 해당 데이터 모듈 이름과 동일합니다. 예를 들어 데이터 모듈 단위의 이름은 CustomersDM.pas입니다.
일반단위의 명칭은 그 목적을 표현해야 하며 앞에 "u"를 붙여야 한다. 예를 들어, 실용적인 디버깅 도구 유닛의 이름은 uDebugUtilities.pas이고, 전역 변수를 포함하는 유닛의 이름은 uCustomerGlobals.pas입니다.
단위 이름은 프로젝트 내에서 고유해야 합니다. 공통 단위 이름은 동일한 이름을 가질 수 없습니다.
구성 요소 셀은 구성 요소를 정의하는 셀임을 나타내기 위해 별도의 경로에 배치되어야 합니다. 일반적으로 프로젝트와 동일한 경로에 배치되지 않습니다. 유닛 파일 이름은 해당 내용을 표현해야 합니다.
구성 요소 명명 표준에 대한 자세한 내용은 "구성 요소 유형 명명 표준"을 참조하세요.
구성 요소 셀에는 구성 요소 팔레트에 나타나는 구성 요소인 기본 구성 요소가 하나만 포함될 수 있습니다. 다른 보조 구성 요소나 개체도 동일한 장치에 포함될 수 있습니다.
구성요소 등록 프로세스는 구성요소 단위에서 벗어나 별도의 단위에 배치되어야 합니다. 이 등록 단위는 모든 컴포넌트, 속성 편집기, 컴포넌트 편집기, 마법사 등을 등록하는 데 사용됩니다.
컴포넌트 등록은 디자인 패키지에서 이루어져야 합니다. 따라서 등록 단위는 런타임 패키지가 아닌 디자인 타임 패키지에 포함되어야 합니다. 등록 단위의 이름은 다음과 같이 지정하는 것이 좋습니다.
xxxReg.pas
그 중 xxx 문자 접두사는 구성 요소 패키지 이름이나 회사, 개인 또는 기타 개체를 식별하는 데 사용됩니다. 예를 들어 등록 단위의 이름은 xxxReg.pas입니다.
런타임 패키지에는 필수 단위만 포함되어야 합니다. 속성 편집기와 구성 요소 편집기의 해당 요소는 디자인 타임 패키지에 배치되어야 합니다. 등록 단위도 설계 단계 패키지에 포함되어야 합니다.
패키지 이름 지정은 다음 패턴을 따릅니다.
dciiiDescvvCn.pkg —디자인 패키지
iiiDescvvCn.pkg —런타임 패키지
그 중 iii는 식별해야 하는 회사, 개인 또는 기타 항목을 식별하는 데 사용되는 2-3자의 접두사를 나타냅니다. Desc는 제어 패키지의 버전 번호를 나타냅니다. 패키지. 필요에 따라 선택할 수 있습니다. 접두사 "dcl"은 디자인 타임 패키지를 나타내며, 이 접두사가 없는 문자 "Cn"은 다음과 같은 컴파일러 유형 및 컴파일러 버전 번호를 나타냅니다. 델파이5=D5, 델파이4=D4, CBuilder3=C3....
패키지 이름의 lib 또는 std는 각각 디자인 타임 패키지인지 런타임 패키지인지를 나타냅니다. 예를 들어:
dclrbStdComPSD5.pkg - Delphi 5 디자인 타임 패키지
rbStdCompsD5.pkg —Delphi 5 런타임 패키지
대부분의 코드 자동 서식 지정 도구는 소스 프로그램 형식을 재정렬하고 예약어 및 식별자의 대문자 사용을 업데이트하는 데 도움이 되지만 버전 제어를 이미 사용한 경우에는 버전 제어를 사용하지 않는 것이 좋습니다. 자동 코드 서식 도구를 쉽게 사용하지 마십시오. 공백이 하나 더 있어도 버전 관리 도구는 해당 행이 수정된 것으로 간주하여 프로그램 관리에 변경을 초래합니다.