object pascal style guide (kor)
DESCRIPTION
Pascal Style Guide (KOR)TRANSCRIPT
Object Pascal Style Guide
Original by Charles Calvert
이 문서는 델파이 코드를 포맷팅하는데 필요한 표준 스타일을 문서화한 것으로, 델파이 팀이 만든 규칙을
기본으로 하고 있습니다. 체계가 확립된 회사들은 여기에 규정한 것과 다른 규칙을 가지고 있을 것입니다.
그러나 여러분의 소스를 볼랜드, Project JEDI 등의 공동 소스 리포지토리에 제출하기 전에 볼랜드 스타일에 맞게
소스를 변환하기를 강력히 권장합니다. 그렇다고 하여 여러분의 규칙을 바꾸기를 원하지는 않습니다. 그러나
볼랜드 제품을 탑재한 코드는 이 규칙을 지키고 있습니다. 또한 공공 리포지토리에 소스를 제공할 경우 이
규칙을 지킬 것을 권장합니다.
오브젝트 파스칼은 아름답게 설계된 언어로서, 중요한 장점 중 하나는 가독성입니다. 이 표준은 오브젝트 파스칼
코드의 가독성을 향상시키고자 만들어졌습니다. 개발자들이 이 안내서의 손쉬운 규칙을 따른다면, 읽기 쉬운
단일한 스타일이 널리 사용되고, 표준은 보다 보편화므로 모든 델파이 개발자들에게 도움이 됩니다. 표준을
지키게 되면 특히 유지보수나 디버깅 단계에서 개발자의 소스 코드 가치가 커지게 됩니다.
규칙이란 단지 개별 선호도 문제일 뿐임에도 불구하고 우리가 이 스타일을 존중하고 추구합니다. 그 이유는
이것만이 옳고 다른 것이 틀리기 때문이 아니라, 표준을 대부분의 개발자들이 따르게 될 때의 효과 때문입니다.
사람들은 표준에 적응하여 친숙한 패턴을 쉽게 찾을 것이며, 빠르고 쉽게 의미를 이해하게 될 것입니다. 많은
사람들이 가능한 쉽게 코드를 읽도록 하는 것이 표준을 만든 이유입니다. 처음에는 이 가이드라인이 익숙하지
않겠지만 따르도록 노력해 보십시오. 그러면, 점차 익숙해 질 것입니다. 여러분만의 포맷을 선호한다면, 볼랜드나
공동 리포지터리에 제출하기 전에 이 가이드라인에 맞게 프로그램으로 변경하십시오. Visual SlickEdit 와 같은
텍스트 에디터를 이용하여 특정한 방식에 따라 코드를 포맷할 수 있습니다.
Egbert van Nes 가 개발한 무료 포매터는 다음 주소에서 이용할 수 있습니다.
http://www.slm.wau.nl/wkao/delforexp.html.
상업적으로 판매하는 제품은 CrackerJax for Delphi 입니다.
http://www.kineticsoftware.com/html/products.html.
볼랜드 웹 사이트와 제품 CD 에서는 이 기준이 반드시 지켜지고 있습니다. 일관되고 읽기 쉬운 스타일로 코드를
작성할 수 있는 가장 간단한 방법은 바로 이 가이드의 규칙을 지키는 것입니다.
웹 상에 이 문서는 올리지 말고, 주소만 단순 링크하십시오. 수정이나 제안 사항은 Charlie Calvert 에게 연락
주시면 반영할 것입니다. 원문 링크: http://edn.embarcadero.com/article/10280
목차
1.0 소개 ......................................................................................................................................................... 3
1.1 배경 ........................................................................................................................................................................................ 3
1.2 감사의 말 .............................................................................................................................................................................. 3
2.0 소스 파일 ............................................................................................................................................... 3
2.1 소스 파일 명명법 ................................................................................................................................................................ 3
2.2 소스 파일 구성 .................................................................................................................................................................... 3
2.2.1 저작권/ID 블럭 주석 ..................................................................................................................................................................... 4
2.2.2 유닛 선언부 ....................................................................................................................................................................................... 4
2.2.3 uses 선언부 ........................................................................................................................................................................................ 5
2.2.4 클래스/ interface 선언부 ............................................................................................................................................................. 5
3.0 명명 규칙 ............................................................................................................................................... 6
3.1 유닛 명명법 .......................................................................................................................................................................... 6
3.2 클래스/ Interface 명명법................................................................................................................................................... 6
3.3 필드 명명법 .......................................................................................................................................................................... 6
3.4 메소드 명명법 ...................................................................................................................................................................... 6
3.5 지역 변수 명명법 ................................................................................................................................................................ 7
3.6 예약어 .................................................................................................................................................................................... 7
3.7 타입 선언부 .......................................................................................................................................................................... 7
4.0 여백 사용법 ........................................................................................................................................... 7
4.1 빈 줄 ................................................................................................................................................................................. 7
4.2 빈 칸 ...................................................................................................................................................................................... 7
4.2.1 공란 사용을 금함: .......................................................................................................................................................................... 7
4.3 들여쓰기 ................................................................................................................................................................................. 8
4.4 연속 행 .................................................................................................................................................................................. 8
5.0 주석 ......................................................................................................................................................... 9
5.1 블록 주석 .............................................................................................................................................................................. 9
5.2 한 줄 주석 .......................................................................................................................................................................... 10
6.0 클래스 ................................................................................................................................................... 11
6.1 클래스 바디 구성 .............................................................................................................................................................. 11
6.1.1 액세스 레벨 .................................................................................................................................................................................... 11
6.1.8 생성자 선언부 ............................................................................................................................................................................... 11
6.2 메소드 선언부 .................................................................................................................................................................... 11
7.0 인터페이스 ........................................................................................................................................... 12
7.1 인터페이스 바디 구성 ...................................................................................................................................................... 12
8.0 문장 ....................................................................................................................................................... 12
8.1 단순문 .................................................................................................................................................................................. 12
8.1.1 대입문과 표현식 ........................................................................................................................................................................... 12
8.1.2 지역 변수 선언부 ........................................................................................................................................................................ 12
8.1.3 배열 선언부 .................................................................................................................................................................................... 13
8.2 복합문 .................................................................................................................................................................................. 13
8.2.3 if 문..................................................................................................................................................................................................... 13
8.2.4 for 문 ................................................................................................................................................................................................. 14
8.2.5 while 문 ............................................................................................................................................................................................ 14
8.2.6 repeat 문 .......................................................................................................................................................................................... 15
8.2.7 case 문 .............................................................................................................................................................................................. 15
8.2.8 try 문 ................................................................................................................................................................................................. 16
1.0 소개 이 문서는 오브젝트 파스칼 언어의 문법을 정의하는 것이 아닙니다. 예를 들면, else 절 앞에
세미콜론(;)을 넣는 것은 잘못된 것으로 컴파일러는 이것을 허용하지 않습니다. 이 스타일 가이드 문서는
이러한 문법에 대한 내용이 아닙니다. 이 문서는 언어가 선택의 여지를 주는 영역 대한 적절한 가이드를
제공합니다. 따라서 선택의 여지가 없는 경우에 관해서는 언급하지 않습니다.
1.1 배경 이 가이드라인은 델파이 소스의 공개 부분을 기반으로 하며, 델파이 소스는 이 가이드라인을 정확히
따라야 합니다. 만약 이 가이드라인에 어긋나는 소스에서 발견할 경우에는, 잘못된 소스 코드를 따르지
말고, 이 가이드라인을 표준으로 삼아야 할 것입니다. 그러나 잘못된 소스 코드를 보고 잘못되었다는
생각이 들지 않는다면, 그러한 코드는 가이드라인을 보조하는 용도로 사용되어도 됩니다.
1.2 감사의 말 이 문서의 형식과 언어의 일부는 자바 언어의 스타일 표준 작업에 기반을 두고 있습니다. 자바가
오브젝트 파스칼 소스를 포맷팅하는 기준에 영향을 주지는 않았으나, Sun 웹 사이트 문서들은 이
가이드의 틀을 제공하였습니다. 특히 이 가이드의 양식과 포맷은 Achut Reddy 가 쓴 "A Coding Style
Guide for Java WorkShop and Java Studio Programming" 의 많은 영향을 받았습니다. 그 문서는
http://www.sun.com/workshop/java/wp-coding 에서 찾아볼 수 있습니다. 델파이 팀 또한 이 문서를
만드는데 많은 기여를 하였으며, 그러한 도움이 없었다면 이 문서를 만들 수 없었을 것입니다.
2.0 소스 파일 오브젝트 파스칼 소스는 유닛(unit)과 델파이 프로젝트 파일로 구성되어 있고, 각각 동일한 규칙을 따르고
있습니다. 델파이 프로젝트 파일은 DPR 확장자로 되어 있으며 프로젝트의 주요 소스 파일입니다.
프로젝트에 사용되는 각각의 유닛은 PAS 확장자로 되어 있습니다. 배치 파일, html 파일, DLL 등이
프로젝트에 사용될 수 있으나, 이 문서는 DPR 파일과 PAS 파일에 관한 포맷 만을 다룰 것입니다.
2.1 소스 파일 명명법 오브젝트 파스칼은 긴 파일 이름(LFN)을 지원합니다. 한 개의 이름을 만들기 위해 여러 개의 단어를
사용할 경우, 각각의 단어는 대문자로 시작합니다.(예: MyFile.pas, InfixCaps 혹은 Camel Caps 방식이라고
합니다) 확장자는 소문자를 사용합니다. 역사적인 이유로 종종 델파이 소스가 8:3 파일 명명 형태를
따르고 있지만, 개발자는 이러한 규칙에 제약을 받을 필요는 없습니다.
C/C++ 헤더 파일을 컨버전하는 경우, 번역하는 파일과 동일한 이름을 가지고 확장자만 PAS 로 마칩니다.
예를 들면, Windows.h 는 Windows.pas 가 됩니다. 파스칼 문법 규칙에 따라 여러 개의 헤더 파일을
하나의 유닛으로 만들 경우, 다른 파일을 포함하는 기본 유닛의 이름을 사용합니다. 예를 들면,
Windows.h 가 WinBase.h 를 포함하면, 결과 파일은 Windows.pas 가 됩니다.
2.2 소스 파일 구성
모든 오브젝트 파스칼 유닛은 다음 요소를 아래 순서에 따라 포함하고 있어야 합니다.
1. 저작권/ID 블록 주석
2. 유닛 이름
3. interface 섹션
4. Implementation 섹션
5. 마지막 end 와 기간
각 요소들 사이에는 적어도 한 줄 이상의 빈 공간을 두어 각각을 구분할 수 있어야 합니다. 저작권, 유닛
이름 다음에 컴파일러 지시문 및 주석과 같은 추가적인 정의를 적당한 곳에 기술할 수 있으며 그 다음에
uses 절이 와야 합니다.
{*******************************************************}
{ }
{ Borland Delphi Visual Component Library }
{ }
{ Copyright (c) 1995,98 Inprise Corporation }
{ }
{*******************************************************}
unit Buttons;
{$S-,W-,R-}
{$C PRELOAD}
interface
uses
Windows, Messages, Classes,
Controls, Forms, Graphics,
StdCtrls, ExtCtrls, CommCtrl;
상수 섹션 앞에 타입 섹션을 기술하거나, 상수 섹션과 타입 섹션을 원하는 순서대로 섞어 사용할 수
있습니다.
implementation 섹션은 예약어 implementation 으로 시작하며 그 다음에 uses 절을 사용하고, 다른
문장이나 지시어를 사용합니다.
implementation
uses
Consts, SysUtils, ActnList,
ImgList;
{$R BUTTONS.RES}
2.2.1 저작권/ID 블럭 주석
모든 소스 파일은 버전 정보와 저작권을 소개하는 블럭 주석으로 시작합니다. 버전 정보는 다음과 같은
포맷을 따릅니다.
{*******************************************************}
{ }
{ Widgets Galore }
{ }
{ Copyright (c) 1995,98 Your Company }
{ }
{*******************************************************}
저작권 소개는 적어도 다음 줄을 포함하고 있어야 합니다.
Copyright (c) 연도 저작권자.
만약 Borland 를 위해 파일을 제작하는 써드 파티라면, 저작권 소개 다음에 여러분의 이름을 넣을 수
있습니다.
{*******************************************************}
{ }
{ Borland Delphi Visual Component Library }
{ Copyright (c) 1995,99 Borland International }
{ Created by Project JEDI }
{ }
{*******************************************************}
2.2.2 유닛 선언부
모든 소스 파일은 유닛 선언부를 가지고 있습니다. unit 단어는 예약어로 소문자로 표현합니다. 유닛
이름은 대소문자를 함께 사용할 수 있고, OS 의 파일 시스템에서 사용되는 파일 이름과 동일해야 합니다.
예를 들면:
unit MyUnit;
이 유닛은 파일 시스템에서 MyUnit.pas 로 불릴 것입니다.
2.2.3 uses 선언부
유닛 안에서 uses 선언부는 소문자 uses 로 시작하고, 유닛 선언부에서 사용된 대소문자 규칙에 따라
유닛의 이름을 기술합니다.
uses MyUnit;
각각의 유닛은 콤마로 구분되며 마지막 유닛 이름 다음에 세미콜론을 넣습니다.
uses
Windows, SysUtils, Classes, Graphics, Controls, Forms,
TypInfo;
위의 예처럼 uses 절 다음 줄부터 유닛 목록을 기술할 수 있으나, 같은 줄에 기술할 수도 있습니다.
uses Windows, SysUtils, Classes, Graphics, Controls, Forms, TypInfo;
uses 절에 유닛 목록을 기술할 수 있으나, 80 자가 넘을 경우 다음 줄에 기술합니다.
2.2.4 클래스/ interface 선언부
클래스 선언은 앞에 칸을 두 칸 비워두고 대문자 T 를 식별자로 붙입니다. 식별자는 대문자로 시작해야
하며, InfixCaps 방식을 명명합니다. 소스 내에서 탭 문자는 사용하지 않습니다. 예를 들면
TMyClass
빈 칸과 식별자로 시작하는 클래스 명을 넣고, 등호 표시를 하고, 소문자 class 를 넣습니다.
TMyClass = class
만약 조상 클래스를 선언하고 싶다면, 괄호 표시를 하고 조상 클래스 명을 기술합니다.
TMyClass = class(TObject)
유효범위 지정자는 줄 앞에서 칸을 두 칸 비워놓고 시작하며 아래 예에 나타나는 순서로 선언되어야
합니다.
TMyClass = class(TObject)
private
protected
public
published
end;
private 데이터는 private 섹션에 선언되어야 하고 식별자 F 로 시작합니다. 모든 형태의 선언은 줄 앞 에
칸을 네 칸 비워놓고 시작합니다.
TMyClass = class(TObject)
private
FMyData: Integer;
function GetData: Integer;
procedure SetData(Value: Integer);
public
published
property MyData: Integer read GetData write SetData;
end;
Interface 선언 방식은 클래스와 유사합니다. 그러나 유효범위 지정을 하지 않으며, class 대신 interface
단어를 사용합니다.
3.0 명명 규칙 예약어와 지시어를 제외하고 모든 파스칼 식별자는 InfixCaps 방식을 따라야 합니다. 즉 단어의 첫
알파벳은 대문자를 쓰고 나머지는 소문자를 쓰며, 여러 개의 단어로 구성된 식별자의 경우 각각의
단어는 동일한 방식을 따릅니다. 그리고 식별자 내에서 사용된 머리글자 역시 같은 방식을 따릅니다.
MyIdentifier
MyFTPClass
중요한 것은 이 규칙은 헤더에서는 예외라는 것입니다. 헤더는 다른 규칙을 따라야 합니다. 예를 들면,
LButtonDown 이 아닌 LBUTTONDOWN 라 기술하여야 합니다.
헤더 작성 시 단어를 분리하기 위해 언더스코어를 사용하지 않습니다. 클래서 명은 명사나 명사구를
사용합니다. 클래스나 Interface 명은 사용하는 중요한 목적을 표현합니다.
올바른 명명법: AddressForm, ArrayIndexOutOfBoundsException
잘못된 명명법:
ManageLayout // 동사구 verb phrase
delphi_is_new_to_me // 언더스코어 underscores
3.1 유닛 명명법 이 절 도입부에서 설명한 InfixCaps 방식을 사용합니다. 유닛 선언부를 참조하십시오.
3.2 클래스/ Interface 명명법 이 절 도입부에서 설명한 InfixCaps 방식을 사용하고, 타입 식별자 대문자 T 로 시작합니다.
TMyType
클래스/ interface 선언부를 참조하십시오.
3.3 필드 명명법 이 절 도입부에서 설명한 InfixCaps 방식을 사용하며, 타입 식별자인 대문자 F 로 시작합니다. private
섹션 안에 모든 데이터 타입을 선언하며, public 액세스 제공을 위해서는 속성이나 getter, setter 를
사용합니다. 예를 들면, 내부 필드 값을 반환하는 함수를 GetSomething 이라는 이름으로 만들어서
사용하고, 그 값을 변경하는 프로시저를 SetSomething 이름으로 만들어서 사용합니다.
헤더 컨버전에 필요한 경우가 아니라면, 상수 선언시 대문자로만 사용하지 않습니다.
델파이는 캘리포니아에서 만들어졌습니다. 따라서 헤더 컨버전을 제외하고는 전체 대문자 표기를
자제합니다.
바른 표기 FMyString: string;
잘못된 표기 lpstrMyString: string;
예외적으로, 헝가리언 표기법이 적용되는 경우는 열거(enumerated) 타입입니다. TBitBtnKind = (bkCustom, bkOK, bkCancel, bkHelp,
bkYes, bkNo, bkClose, bkAbort, bkRetry,
bkIgnore, bkAll);
위의 경우 bk 가 각각의 열거 타입 요소들 앞에 붙여집니다. bk 는 ButtonKind(버튼종류)를 나타냅니다.
명명 규칙을 고려할 때 한 글자로 된 필드명은 자제합니다. 한글자는 임시적으로 사용하거나 순환문에서
사용될 수 있습니다.
변수 l (소문자 L") 은 화면상이나 출력 시 1 (숫자 1) 과 구분하기 어렵기 때문에 사용을 피해야만 합니다.
.
3.4 메소드 명명법 메소드 이름은 InfixCaps 방식을 따라야 합니다. 즉, 대문자로 시작해야 하며, 이름 안에 있는 각 단어의
첫 문자와 머리글자어의 각 문자들도 대문자를 사용합니다. 각 단어의 분리를 위한 용도로 언더스코어를
사용하지 않습니다. 이것은 상수가 아닌 필드의 명명 규칙으로 일정하게 사용하는 것입니다. 그러나
메소드 이름은 명령문의 동사나 동사구로 구성되어 있습니다.
예:
// 바른 메소드 명명: ShowStatus, DrawCircle, AddLayoutComponent
// 잘못된 메소드 명명:
MouseButton // 명사구, 기능을 설명하지 않습니다.
drawCircle // 소문자로 시작합니다.
add_layout_component // 언더스코어
// 아래 메소드는 기능이 명확하지 않습니다.
// 서버를 구동(StartServer 가 좋고)한다는 것인가요? 아니면
// 서버기 작동하는지 테스트(IsServerRunning 가 좋고)한다는 것인가요?
ServerRunning // 동사구이지, 명령문이 아닙니다.
클래스의 속성 값을 받거나 정의하는 메소드는 GetProperty 혹은 SetProperty 라 부릅니다. Property 는
속성의 이름을 사용합니다.
예: GetHeight, SetHeight
클래스의 부울(boolen) 속성을 테스트하는 메소드 이름이 IsVisible 이라면, 속성 이름이 Visible 인 경우
입니다.
예: IsResizable, IsVisible
3.5 지역 변수 명명법 지역 변수는 필드 명명 규칙과 동일합니다. 단, 오브젝트의 필드가 아니기 때문에 식별자 F 를
생략합니다. (3.3 참조)
3.6 예약어 예약어와 지시어는 모두 소문자를 사용합니다. 이것은 종종 혼란스럽게 할 것입니다. 예를 들면, Integer
같은 인스턴스 타입은 식별자이므로 대문자로 시작합니다. 그러나 문자열은 소문자로 구성된 예약어
string 으로 선언됩니다.
3.7 타입 선언부 타입 선언은 모두 글자 T 로 시작하며, 서두의 안내 또는 클래스/ interface 선언부를 참조하십시오
4.0 여백 사용법
4.1 빈 줄 빈 줄을 사용하면 논리적으로 연관 있는 코드 섹션을 그룹화하여 가독성을 향상시킵니다. 빈 줄은 또한
아래와 같은 곳에서 사용할 수 있습니다.
1. 저작권 블록 주석 , 패키지 선언, 임포트 섹션 뒤
2. 클래스 선언 사이
3. 메소드 선언 사이
4.2 빈 칸 오브젝트 파스칼은 매우 명료하고, 읽기 쉬운 언어입니다. 일반적으로, 줄을 나누기 위해 많은 빈 칸을
삽입할 필요는 없습니다. 아래에 기술된 사항은 코드에 빈칸을 넣는 가이드라인을 제공할 것입니다.
4.2.1 공란 사용을 금함:
1. 메소드 이름과 왼쪽 괄호 사이
2. .(dot) 연산자 앞과 뒤
3. 단항연산자와 피연산자 사이
4. 캐스트 식별자와 표현식 사이
5. 왼쪽 괄호 다음과 오른쪽 괄호 앞
6. 왼쪽 꺽쇠괄호( [ ) 다음과 오른쪽 꺽쇠괄호( ] )앞
7. 세미콜론 앞
바른 사용 예:
function TMyClass.MyFunc(var Value: Integer);
MyPointer := @MyRecord;
MyClass := TMyClass(MyPointer);
MyInteger := MyIntegerArray[5];
잘못된 사용 예:
function TMyClass.MyFunc( var Value: Integer ) ;
MyPointer := @ MyRecord;
MyClass := TMyClass ( MyPointer ) ;
MyInteger := MyIntegerArray [ 5 ] ;
4.3 들여쓰기 들여쓰기는 레벨에 따라 항상 두 칸씩 들여쓰기를 해야 합니다. 들여쓰기 첫번째 레벨은 두 칸, 두번째
레벨은 네 칸, 세번째 레벨은 여섯 칸을 들여씁니다. 그리고 절대로 탭은 사용하지 않습니다.
몇 개의 예외가 존재합니다. unit, users, type, interface, implementation, initialization 그리고 finalization 과
같은 예약어는 줄 앞에서 시작합니다. 그리고 유닛 절의 끝에 기술하는 end 또한 줄 앞에서 시작합니다.
프로젝트 파일에서 program 이라는 단어와 메인 블럭은 줄 앞에서 시작합니다. 블럭 안의 코드는 두 칸
들여쓰기를 합니다.
4.4 연속 행 한 행은 80 칸으로 제한합니다. 80 칸 이상의 행은 필요에 따라 한 개 이상의 연속 행으로 나누어야
합니다. 모든 연속 행은 절의 첫째 줄과 같이 시작하거나, 들여쓰기를 합니다. 그리고 begin 문은 항상
새로운 줄에서 시작합니다.
예:
// 바른 사용법
function CreateWindowEx(dwExStyle: DWORD;
lpClassName: PChar; lpWindowName: PChar;
dwStyle: DWORD; X, Y, nWidth, nHeight: Integer;
hWndParent: HWND; hMenu: HMENU; hInstance: HINST;
lpParam: Pointer): HWND; stdcall;
// 바른 사용법
if ((X = Y) or (Y = X) or
(Z = P) or (F = J) then
begin
S := J;
end;
파라미터와 타입은 줄 바꿈을 하지 않습니다. 만약 콤마로 분리된 리스트가 아닐 경우 적어도 마지막
파라미터 앞까지 쓰고, 타입 명은 다음 줄에 씁니다. 변수 선언을 위한 콜론과 변수 명 사이에 빈 칸을
넣지 않습니다. 대신 콜론과 타입 명 사이에 빈 칸을 넣습니다.
// 바른 사용법
procedure Foo(Param1: Integer; Param2: Integer);
// 잘못된 사용법
procedure Foo( Param :Integer; Param2:Integer );
연속 행은 이항 연산자로 시작할 수 없습니다. 메소드 명과 왼쪽 괄호, 배열 이름과 왼쪽 꺽쇠괄호 같이
빈 칸을 사용하지 않는 곳에서 줄을 넘기지 않습니다. 만약 이런 환경에서 줄 바꿈을 해야 한다면,
메소드 명 다음에 오는 왼쪽 괄호가 적당합니다. begin 문은 같은 줄에서 다른 코드와 함께 기술하지
않습니다.
예:
// 잘못된 사용법
while (LongExpression1 or LongExpression2) do begin
// DoSomething
// DoSomethingElse;
end;
// 바른 사용법
while (LongExpression1 or LongExpression2) do
begin
// DoSomething
// DoSomethingElse;
end;
// 바른 사용법
if (LongExpression1) or
(LongExpression2) or
(LongExpression3) then
5.0 주석 오브젝트 파스칼 언어는 두 가지 방식의 주석(블록 주석과 한 줄 주석)을 사용할 수 있습니다. 주석
사용에 관한 가이드라인은 다음과 같습니다.
o 목적을 설명하기 위해 유닛 상부에 주석을 기술합니다.
o 클래스 선언 앞에 주석을 기술합니다.
o 메소드 선언 앞에 주석을 기술합니다.
o 쉽게 알 수 있는 주석은 피합니다: i := i + 1; // Add one to i
o 오해하기 쉬운 주석은 사용하지 않는 것이 낫습니다.
o 구식이 되기 쉬운 정보는 주석에 넣지 않습니다.
o 별표나 특별한 활자로 표현한 박스로 주석을 싸지 않습니다.
o 변경해야 되거나 삭제할 필요가 있는 임시 주석은 "???:"와 같은 특별한 태그를 표시하여 나중에
발견하기 쉽게 합니다.
예:
// ???: 고쳐지고 나면 Sort 를 호출 할 수 있도록 바꿀 것
List.MySort;
5.1 블록 주석 오브젝트 파스칼은 두 가지 형태의 블록 주석을 제공합니다. 가장 일반적으로 사용하는 방식은 중괄호:{ }
입니다. 델파이 팀은 단순하고 간결한 구조인 이런 형태의 주석 사용을 선호합니다. 예를 들면 주석
안에서 형태나 줄을 표현하기 위해 별표(*) 사용은 하지 않습니다. 대신에 워드 프로세스 문서에서 주로
사용하듯이 빈 칸을 이용하여 주석을 나눕니다. DsgnIntf.pas 발췌문에 나타나듯이 주석에서 사용하는
단어는 첫번째 중괄호와 같은 줄에서 시작합니다.
{ TPropertyEditor
Edits a property of a component, or list of components,
selected into the Object Inspector. The property
editor is created based on the type of the
property being edited as determined by the types
registered by...
etc...
GetXxxValue
Gets the value of the first property in the
Properties property. Calls the appropriate
TProperty GetXxxValue method to retrieve the
value.
SetXxxValue Sets the value of all the properties
in the Properties property. Calls the appropriate
TProperty SetXxxxValue methods to set the value. }
블록 주석은 소스 파일 시작 위치에서 저작권 주석을 위해 사용합니다. 또한 여러 줄의 코드에 대한
주석을 나타내기 위해서도 사용합니다. 그리고 메소드 선언부 앞에서 메소드를 설명하기 위해
사용합니다.
예:
// 바른 사용법
{ TMyObject.MyMethod
This routine allows you to execute code. }
procedure TMyObject.MyMethod;
begin
end;
// 잘못된 사용법
procedure TMyObject.MyMethod;
{******************************************************
TMyObject.MyMethod
This routine allows you to execute code.
*******************************************************}
begin
end;
두번째 형태의 블록 주석은 괄호와 별표: (* *)를 사용하며 star paren 주석이라 합니다. 이 방법은 코드
개발 단계에 일반적으로 사용합니다. 이 방법의 장점은 두 단계 이하의 하위 주석을 포함할 수 있다는
점입니다.
오브젝트 파스칼은 동일한 형태의 하위 주석을 허용하지 않기 때문에 표준 파스칼 주석은 중첩될 수
없습니다. 하지만, star paren 주석 내에서는 가능합니다. 따라서 코드와 주석이 혼합된 한 뭉치의 코드를
한꺼번에 주석 처리할 때 유용합니다.
(* procedure TForm1.Button1Click(Sender: TObject);
begin
DoThis; // Start the process
DoThat; // Continue iteration
{ We need a way to report errors here, perhaps using
a try finally block ??? }
CallMoreCode; // Finalize the process
end; *)
위의 예를 보면, Button1Click 메소드는 전체가 주석 처리가 되어 있고, 프로시저 begin..end 사이에 하위
주석이 들어 있습니다.
5.2 한 줄 주석 한 줄 주석 처리는 // 문자와 텍스트로 이루어져 있습니다. // 와 주석 사이에는 한 개의 빈 칸을 넣습니다.
한 줄 주석은 코드의 들여쓰기 레벨과 동일한 위치에서 시작합니다. 또한 많은 주석을 넣기 위해 한 줄
주석을 그룹으로 구성할 수 있습니다. 한 줄 주석이나 주석 그룹이 블록의 첫 째 줄이 아니면 항상 빈
줄로 시작하고 주석 마지막에 빈 줄을 삽입합니다. 복합문 등에서 다음 문장에만 적용된다면 빈 줄이 올
필요가 없습니다.
예:
// Open the database
Table1.Open;
한 줄 주석은 참조하는 코드 다음에 올 수 있습니다. 이러한 주석을 trailing 주석이라 하고, 코드와
동일한 줄에 나타납니다. 이 방법은 참조하는 코드와 분리하기 위해 적어도 한 개의 빈 칸으로 분리해야
합니다. 만약 코드 블록에 한 개 이상의 trailing 주석을 사용한다면 동일한 칼럼에 정렬합니다.
예:
if (not IsVisible) then
Exit; // nothing to do
Inc(StrLength); // reserve space for null terminator
실행 코드 매 줄마다 주석을 다는 것은 금합니다. 메소드나 함수의 begin..end 사이에서 주석을
최소한으로 사용하고, 장문의 주석은 메소드와 함수 선언절 앞에서 블록 주석을 사용합니다
6.0 클래스
6.1 클래스 바디 구성 클래스 선언부의 바디는 다음 순서로 구성되어야 합니다.
o 필드 선언
o 메소드 선언
o 속성 선언
클래스의 필드, 속성, 메소드는 알파벳 순서로 이름을 나열합니다.
6.1.1 액세스 레벨
IDE 에 의해 삽입된 코드를 제외하고, 클래스의 유효범위 지시어는 다음 순서에 따라 선언됩니다.
o Private 선언
o Protected 선언
o Public 선언
o Published 선언
오브젝트 파스칼에서 클래스 멤버에 대한 액세스 레벨은 published, public, protected, private 순서로 접근
수준이 낮아집니다. 디폴트 액세스 레벨은 published 이고, 일반적으로 멤버에게는 꼭 필요한 수준에
맞게 가장 낮은 액세스 레벨을 지정합니다. 예를 들면, 동일한 유닛의 클래스에 의해서만 액세스되는
멤버는 private 액세스를 지정합니다. 또한 낮은 단계의 액세스 레벨을 선언하는 것은 최적화를 위해
컴파일러가 많은 노력을 하게 합니다. 즉, private 레벨을 사용하는 것은 파생 클래스로 확장하는 것을
어렵게 합니다. 장차 파생 클래스로 확장될 가능성이 있고, 파생 클래스가 필요한 멤버는 private 대신
protected 를 선언하고, private 데이터를 액세스하는 속성은 protected 를 선언합니다. 데이터는 public
액세스를 선언하지 않습니다. 대신, getter 나 setter 메소드를 이용하거나, 속성을 통해 데이터에
액세스합니다.
6.1.8 생성자 선언부
메소드는 알파벳 순서에 따라 정렬합니다. 생성자와 소멸자는 public 섹션에서 메소드 목록 앞에 넣거나,
public 섹션 내에 알파벳 순서에 따라 정렬합니다. 동일한 이름의 여러 개의 생성자가 있을 경우 형식
파라미터 목록 수가 적은 것을 먼저 기술합니다. 인자가 없는 경우는 항상 맨 앞에 기술합니다.
6.2 메소드 선언부 가능하면 메소드 선언부는 한 줄에 기술합니다.
예:
// 다음 줄은 왼쪽에서 두 칸 들여쓰기를 합니다.
procedure ImageUpdate(Image img, infoflags: Integer,
x: Integer, y: Integer, w: Integer, h: Integer
7.0 인터페이스
인터페이스는 클래스 선언부와 유사한 방식으로 선언됩니다.
InterfaceName = interface([Inherited Interface])
InterfaceBody
end;
인터페이스 선언부는 두 칸 들여쓰기를 합니다. 인터페이스 바디는 네 칸 들여쓰기 규칙을 따릅니다.
마지막 end 절은 두 칸 들여쓰기를 하고, 세미콜론(;)으로 끝납니다.
인터페이스 선언부는 필드는 없으나, 속성은 사용 가능합니다. 인터페이스 메소드는 선언을 하지 않으나
public 과 abstract 액세스를 합니다.
.
7.1 인터페이스 바디 구성 인터페이스 선언부의 바디는 다음 순서에 따라 구성됩니다.
o 인터페이스 메소드 선언부
o 인터페이스 속성 선언부
인터페이스 속성과 메소드 선언 방식은 클래스의 속성과 메소드 선언 방식과 동일합니다.
8.0 문장 문장은 세미콜론(;)으로 끝나는 여러 줄의 코드로 이루어져 있습니다. 단순문은 한 개의 세미콜론을
가지고 있고, 복합문은 단순문으로 구성되어 있으며, 여러 개의 세미콜론을 가지고 있습니다.
아래는 단순문입니다:
A := B;
아래는 복합문 혹은 구조문입니다:
begin
B := C;
A := B;
end;
8.1 단순문 단순문은 하나의 세미콜론을 포함합니다. 만약 문장의 줄 바꿈이 필요하면, 두 번째 줄은 앞 줄보다 두
칸 들여쓰기를 합니다.
MyValue :=
MyValue + (SomeVeryLongStatement / OtherLongStatement);
8.1.1 대입문과 표현식
각각의 줄은 한 개의 문장을 가지고 있어야 합니다. 예를 들면:
a := b + c; Inc(Count); // INCORRECT
a := b + c; // CORRECT
Inc(Count); // CORRECT
8.1.2 지역 변수 선언부
지역 변수는 Camel Caps 방식을 따릅니다. 클래스의 필드 예약어 F 로 변수 명을 시작하지 않습니다.
var
MyData: Integer;
MyString: string;
한 줄에 동일한 타입의 여러 식별자를 선언할 수 있습니다.
var
ArraySize, ArrayCount: Integer;
이러한 방식은 클래스 선언부에서는 권장되지 않습니다. 클래스에서는 각각의 필드를 타입에 따라 다른
줄에 기술합니다.
8.1.3 배열 선언부
왼쪽 꺽쇠괄호 앞과 오른쪽 꺽쇠괄호 뒤에 빈 칸을 넣습니다.
type
TMyArray = array [0..100] of Char;
8.2 복합문 복합문은 항상 세미콜론으로 끝납니다. 만약 end 절 앞에 있을 경우, 세미콜론은 선택 사항입니다.
begin
MyStatement;
MyNextStatement;
MyLastStatement // 세미 콜론은 옵션
end;
8.2.3 if 문
If 문은 적어도 두 줄에 표현됩니다.
예:
// 잘못된 표현법
if A < B then Dosomething;
// 바른 표현법
if A < B then
Dosomething;
복합 if 문에서 문을 나누는 각각의 요소들은 새로운 줄에서 시작합니다.
예:
// 잘못된 표현법
if A < B then begin
DoSomething;
DoSomethingElse;
end else begin
DoThis;
DoThat;
end;
// 바른 표현법
if A < B then
begin
DoSomething;
DoSomethingElse;
end
else
begin
DoThis;
DoThat;
end;
아래에 변형된 형태의 유효한 문장이 있습니다.
// 바른 표현법
if Condition then
begin
DoThis;
end else
begin
DoThat;
end;
// 바른 표현법
if Condition then
begin
DoThis;
end
else
DoSomething;
// 바른 표현법
if Condition then
begin
DoThis;
end else
DoSomething;
차선의 표현방법:
if Condition then
DoThis
else DoThat;
8.2.4 for 문
예:
// 잘못된 표현법
for i := 0 to 10 do begin
DoSomething;
DoSomethingElse;
end;
// 바른 표현법
for i := 0 to 10 do
begin
DoSomething;
DoSomethingElse;
end;
8.2.5 while 문
예:
// 잘못된 표현법
while x < j do begin
DoSomething;
DoSomethingElse;
end;
// 바른 표현법
while x < j do
begin
DoSomething;
DoSomethingElse;
end;
8.2.6 repeat 문
예:
// 바른 표현법
repeat
x := j;
j := UpdateValue;
until j > 25;
8.2.7 case 문
예:
// 바른 표현법
case Control.Align of
alLeft, alNone: NewRange := Max(NewRange, Position);
alRight: Inc(AlignMargin, Control.Width);
end;
// 바른 표현법
case x of
csStart:
begin
j := UpdateValue;
end;
csBegin: x := j;
csTimeOut:
begin
j := x;
x := UpdateValue;
end;
end;
// 바른 표현법
case ScrollCode of
SB_LINEUP, SB_LINEDOWN:
begin
Incr := FIncrement div FLineDiv;
FinalIncr := FIncrement mod FLineDiv;
Count := FLineDiv;
end;
SB_PAGEUP, SB_PAGEDOWN:
begin
Incr := FPageIncrement;
FinalIncr := Incr mod FPageDiv;
Incr := Incr div FPageDiv;
Count := FPageDiv;
end;
else
Count := 0;
Incr := 0;
FinalIncr := 0;
end;
8.2.8 try 문
예:
// 바른 표현법
try
try
EnumThreadWindows(CurrentThreadID, @Disable, 0);
Result := TaskWindowList;
except
EnableTaskWindows(TaskWindowList);
raise;
end;
finally
TaskWindowList := SaveWindowList;
TaskActiveWindow := SaveActiveWindow;
end;