Delphi 코딩 사양 작성자: Tulipsys 업데이트 날짜: 2003년 12월 16일 목차 1. 일반 관례(명명 - 들여쓰기 및 공백 - 여백 - 대소문자 - 주석) 2. 문장(시작...끝문-if문-case문-for문-while문-반복문-with문-예외처리문) 3. 프로시저 및 함수(이름 지정 및 형식-형식 매개변수-변수-유형-사용자 정의 유형) 4. 객체지향(클래스 이름 지정 및 형식-필드-메소드-속성-메소드 구현)과 관련된 코딩 표준을 공식화하는 목적은 프로그래머 그룹이 동일한 스타일의 코드를 생성하여 팀이 하나의 코드를 형성하고 유지할 수 있도록 하는 것입니다. 특정 스타일. 이 목표가 달성되면 전체 프로젝트의 파일은 프로그래머가 작성한 것처럼 보입니다. 좋은 점은 재미있지만 장점은 각 프로그래머의 코드를 다른 사람이 쉽게 이해할 수 있어 코드의 유지 관리성이 크게 향상되어 유지 관리 비용이 절감된다는 것입니다. 이는 어느 팀에게나 이상적인 상황입니다. 개인의 경우 코딩 규범을 선택하거나 스스로 생성하고 이 규범을 준수하는 것도 좋은 결과를 얻을 수 있습니다. 그건 그렇고, 이것은 매우 유혹적인 목표이지만 달성하기가 그리 어렵지는 않습니다. 프로그래밍 언어마다 고유한 코딩 표준이 있습니다. 코딩 표준은 경험의 요약이라고 할 수 있습니다. 물론 다른 프로그래밍 언어의 표준도 배워야 합니다. 그러므로 다른 사람에게서 배우는 것이 매우 중요합니다. 둘째, 코딩 표준을 사용하는 것은 프로그래머의 작업을 단순화하는 것입니다. "단순화"의 의미는 코드의 양을 줄이는 것이 아니라(반대로 표준을 여러 번 따르면 더 많은 코드를 가져오게 됩니다) 프로그래머의 작업량을 줄이는 것입니다. 코드 수량을 유지하는 데 노력합니다. 프로그래밍은 다양한 관계를 다루는 일은 매우 어려운 작업이며, 다양한 관계 사이에는 불가분의 관계가 있습니다. 프로그래머는 관계를 다루는 데 대부분의 에너지를 소비해야 하며 너무 세부적인 문제에 시간을 낭비하지 않아야 합니다. 프로그램의 아이디어와 구조를 한눈에 이해할 수 있다면 유지관리 계획도 빠르게 수립될 것이다. 또한, 코딩 표준은 참조하고 수정할 수 있는 매우 사용자 친화적인 표준이어야 하며, 사용하기 쉬워야 합니다. 그러나 그룹에서는 모든 사람이 동일한 표준을 사용하는지 확인하십시오. 프로그래밍은 매우 유연한 직업입니다. 유연한 사고와 유연한 적용이 있어야만 좋은 결과를 얻을 수 있습니다. 또한 스펙을 사용하는 이유는 프로그래머의 메모리 부담을 줄이기 위함이 크다. 인간의 사고력은 극히 뛰어나지만 기억력은 매우 형편없습니다. 우리는 하루 종일 컴퓨터를 마주하는데, 인간이 우리에게 도움을 주고자 하는 가장 중요한 일은 기억력입니다. 따라서 프로그래머의 사고 이점을 극대화하는 것이 우리의 목표 중 하나입니다. 마지막으로 프로그래밍 도구는 코딩 표준에 큰 영향을 미치며, 이러한 영향은 개발자의 프로그래밍 스타일에서 비롯됩니다. 또한 C++를 기반으로 하므로 Microsoft Visual C++와 Borland C++ Builder에서 정확히 동일한 코딩 사양을 사용하지 않습니다. Microsoft와 Borland는 서로 다르고 매우 뚜렷한 스타일을 가지고 있습니다. 사용자로서 이를 기반으로 변경할 수 있지만 제한이 있습니다. 실제로 공급업체와 개발 도구를 선택할 때 미래 스타일도 결정됩니다. 1. 일반 관례 1.1 명명 명명의 기본 원칙은 이름이 데이터의 기능을 명확하게 표현해야 한다는 것입니다. 오브젝트 파스칼은 긴 파일 이름을 지원합니다. 이름에는 동사, 명사 또는 둘의 조합을 사용해야 합니다. 델파이에서 정의된 예약어 및 키워드를 사용해서는 안 되며, 다른 언어에서 정의된 예약어 및 키워드도 사용하지 마십시오. 완전한 단어를 사용하고 약어, 접두사, 접미사, 밑줄 또는 기타 기호는 사용하지 않는 것이 좋습니다. 이름의 가독성을 보장하기 위해 명명 규칙이 사용됩니다. 헝가리 명명법으로 표시되는 명명 표준에서는 데이터의 유형, 범위 또는 기타 다양한 속성을 나타내기 위해 많은 접두사와 접미사가 개발되었습니다. 델파이에서는 확실히 이 방법을 사용할 수 있지만 권장되는 방법은 아닙니다. 한 가지 이유는 이러한 유형의 명명 규칙으로 인해 너무 많은 추가 메모리 작업이 발생한다는 점이며, 또 다른 이유는 델파이 자체의 특성에 따라 결정됩니다. Delphi의 필수 유형 검사는 모든 변수의 사용을 자동으로 모니터링하므로 힘들게 다양한 접두사를 추가할 필요 없이 약간만 주의하면 됩니다(단어의 대문자 사용에 주의). 또한, 데이터의 고려는 유형이나 범위보다는 의미에 기초해야 하며, 프로그램 구조, 논리적 관계, 디자인 아이디어에 주목해야 합니다. 따라서 Delphi에서는 이름을 지정하는 데 단어의 완전한 조합만 사용하면 되고 다른 것은 고려하지 말고 가능한 한 간결하게 유지해야 합니다. 일부 명령문(예: for 루프)에서는 여러 정수를 계산 변수로 사용해야 합니다. 여기서는 i, j, k 세 글자를 변수 이름으로 간단히 사용할 수 있습니다. 이는 Fortran 언어에서 개발되고 유지된 습관으로, 매우 유용하고 이해하기 쉬운 것으로 입증되었습니다. 물론 MyCounter와 같이 보다 의미 있는 이름을 사용하면 더 나은 결과를 얻을 수 있습니다. 일반적으로 i, j, k 세 글자이면 충분합니다. 그렇지 않으면 더 많은 프로세스나 기능을 나누어야 합니다. 다음은 몇 가지 예입니다. 1. SongsList //노래 목록임을 나타냅니다. 노래가 복수개 있으면 노래가 두 개 이상 있음을 나타냅니다. 2. SetCarColor //색상을 설정하는 함수임을 나타냅니다. TCar 클래스가 정의된 경우 클래스에서 SetColor가 자동차 색상을 설정하는 함수 멤버로 사용됩니다. 또한 부울 변수의 이름 지정에 주의하세요. 불리언 변수의 이름은 True와 False의 의미를 명확하게 나타내야 합니다. 예를 들어, 파일 존재 여부를 기록하는 변수의 경우 FileExisted를 사용하는 것보다 IsFileExisted를 사용하는 것이 더 좋습니다. 마지막으로 전역 변수 이름을 Temp 또는 Tmp로 지정하지 마십시오. 하지만 프로시저나 함수 내에서는 여전히 허용됩니다. 실제로 이 규칙에 대해서는 약간의 논란이 있습니다. 일부 코딩 표준은 프로시저나 기능에서도 이러한 이름 지정을 절대적으로 금지합니다. 그러나 이 이름 지정은 특히 프로시저나 함수의 경우 매우 편리합니다. 전역 변수로 사용하면 타입이 맞지 않는 대입문이 나올 가능성이 높다. 이때 컴파일러가 많은 도움을 주지만 작은 오류의 발생을 피하기는 어렵다. . 요약하면 이 규칙을 따르면 더 나은 결과를 얻을 수 있지만 필요한 경우 엄격하게 준수해서는 안 됩니다. 1.2 들여쓰기 및 공백 각 레벨 사이에 두 개의 공백을 들여쓰기해야 프로그램이 명확하고 잘 정리됩니다. 탭 문자의 너비는 다양한 설정 및 애플리케이션에서 일관성을 유지하기 어렵기 때문에 절대 탭 문자를 사용하지 마십시오. 그러나 프로그램이 Delphi에서만 표시될 것이라고 기대하지 마십시오. 또한 편집기 사용에 주의하세요. Delphi만 선택하는 경우 문제가 없습니다. Word와 같은 텍스트 프로세서도 사용하는 경우 각 문자와 기호의 너비를 확인하기 위해 적절한 글꼴을 사용하는 데 주의하세요. 동일합니다. Word와 같은 텍스트 프로세서로 인쇄할 때는 글꼴 선택에도 주의해야 합니다. 공백을 사용하는 것은 프로그램을 깔끔하게 유지하고 프로그래머가 프로그램 구조를 빠르게 이해할 수 있도록 하기 위한 것이기도 합니다. 다음은 일부 사양 및 해당 예입니다. 1. 각 단어 사이에는 공백이 있어야 합니다. 예: TMyClass = class(TObject)2． "=", "<>", ">=" 및 "<=" 주위에는 공백이 있어야 하며 ":=" 및 ":"의 오른쪽에는 공백이 있어야 하지만 왼쪽에는 공백이 없어야 합니다. 예: a = b이면 a:= b: 정수 3. 예약어 및 키워드와 왼쪽 기호 사이에는 공백이 있어야 하며, 오른쪽 기호 사이에는 공백이 없어야 합니다. 예: PROcedure ShowMessage; 대괄호 사용: 프로시저와 함수의 정의 및 호출에서 대괄호와 외부 단어 및 기호 사이에 공백이 있어서는 안 됩니다. 대괄호와 내부 단어 사이에 공백이 있어서는 안 됩니다. if문의 조건부 판단에서는 and, or 등 예약어 사이에 공백을 사용해야 한다. 예: function Exchange(a: 정수; b: 정수); if (a = b) and ((a = c) or (a = d)) then … end;1.3 margin 델파이 편집기는 오른쪽에서 약 81번째입니다. 실제로 Delphi의 기본 인터페이스에서는 해상도가 800*600일 때 최대화된 창이 어두운 선 왼쪽에 4글자로 표시됩니다. 따라서 어두운 선 바깥에는 소스 코드를 작성하지 마십시오. 즉, 각 줄은 앞뒤 공백을 포함하여 80자를 넘지 않아야 합니다. 명령문이 너무 길면 줄 바꿈이 완료되고 줄 바꿈은 두 문자만큼 들여쓰기되어야 합니다. 이것도 인쇄하기 쉬우며, 짙은 선 너머의 부분은 델파이에서 인쇄되지 않습니다. Delphi 프로그램을 인쇄하기 위해 Word와 같은 워드 프로세싱 소프트웨어를 사용하는 경우 초과된 부분이 다음 줄의 시작 부분으로 이동되어 인쇄된 프로그램을 읽기 어렵게 만듭니다. 따라서 코드를 작성하면서 모든 조정을 시도하고 이러한 작업을 인쇄에 맡기지 마십시오. 줄 바꿈 시 프로그램의 가독성을 유지하고 전체 부분을 유지하도록 노력하십시오. 예를 들어, 함수가 너무 길면 데이터 유형 선언 대신 전체 매개변수 설명을 래핑하십시오. 아래의 처음 두 가지 작성 방법은 맞지만 다음 작성 방법은 잘못되었습니다. function AdditonFiveInputNumber(a: 정수; b: 정수; c: 정수; d: ineger;e: 정수): //정확한 function AdditonFiveInputNumber; (a: 정수;b: 정수;c: 정수;d: ineger;e: 정수): 정수 //올바른 함수; AdditonFiveInputNumber(a: 정수; b: 정수; c: 정수; d: ineger; e: 정수): 정수; //오류 함수 AdditonFiveInputNumber(a: 정수; b: 정수; c: 정수; d: ineger;e: 정수 ): 정수; //오류 함수 AdditonFiveInputNumber(a: 정수; b: 정수; c: 정수; d: ineger;e: 정수): 정수; //오류 1.4 사용자 정의 이름의 각 단어의 첫 글자는 대문자와 소문자여야 하며, 다른 글자는 소문자여야 합니다. Delphi 예약어와 키워드는 모두 소문자여야 합니다. Delphi의 사전 정의된 함수 작성 방법은 사용자 정의 이름 작성 방법과 동일합니다. Delphi의 기본 데이터 유형은 소문자여야 하며, 확장 클래스 유형의 처음 두 글자는 대문자여야 합니다(클래스 유형의 첫 글자는 "T"입니다). 다음은 몇 가지 예입니다: 1. 사용자 정의 이름: MyFavouriteSong, CarList; 2. 예약어: if (a = b) and ((a = c) 또는 (a = d)) then … end; ('모든 것이 괜찮습니다');4. Delphi 확장 클래스 유형: MyStrings = TStrings.Create;1.5 주석 Delphi는 블록 주석({})과 한 줄 주석(//)이라는 두 가지 유형의 주석을 지원합니다. 코멘트의 목적은 프로그램의 디자인 아이디어를 설명하고 프로그래머가 2년 전 또는 심지어 어제 작성된 프로그램의 아이디어를 가능한 한 빨리 이해할 수 있도록 돕는 것입니다. 이것은 실제로 기억 문제를 해결하기 위한 것입니다. 프로그래밍에서 두뇌를 과도하게 사용해서는 안 되며, 가능한 한 단어를 사용하십시오. 따라서 프로그래밍 언어에서 주석은 매우 중요한 측면이지만 많은 사람들(특히 상당수의 프로그래머를 포함한 초보자)은 이를 신경 쓰지 않고 주석을 거의 작성하지 않습니다. 주석의 또 다른 적용은 프로그램 디버깅 단계에 있습니다. 예를 들어 두 개의 명령문이 있고 어느 것이 더 나은지 미리 알 수 없는 경우 테스트해야 합니다. 명령문 앞에 "//"를 넣으십시오(즉, 변경). 주석을 추가할 명령문), 또 다른 명령문을 실행하고 그 반대를 수행하면 쉽게 선택할 수 있습니다. 명령문 그룹인 경우 블록 주석을 사용하되 "{" 및 "}"를 별도의 위쪽 및 아래쪽 줄과 같이 눈에 띄는 위치에 배치해야 합니다. 1. 다음은 몇 가지 사용 원칙입니다. 대부분의 경우 사용자 정의 변수 및 유형 앞에 주석을 배치해야 합니다. 2. 대부분의 경우 유닛 파일 상단에 코멘트를 추가해야 합니다. 여기서 설명에는 파일 이름, 생성 날짜, 수정 날짜, 작성자, 수정 작성자 및 필요한 설명이 포함되어야 합니다. 3. 댓글은 의미가 있어야 하며, 쓸모없는 댓글은 사용하지 마세요. 예: while i < 8 dobegin … i:= i + 1; //Add one to iend; 여기서 "//Add one to i"라는 주석은 의미가 없습니다. 물론 다음과 유사합니다. i : = i + 1) 설명이 필요하지 않습니다. 간단한 진술이 매우 중요한 역할을 하는 경우가 많기 때문에 이 진술이 사람들에게 의문을 제기하거나 이해하기 어려울 경우 이 진술의 기능을 표시해야 합니다. 4. 꼭 필요하다고 생각하지 않는 한 댓글에 모노그램을 만들려고 하지 마세요. 패턴을 온전하고 아름답게 유지하면서 주석을 수정하는 것은 매우 어렵기 때문입니다. . 5. 임시 주석과 영구 주석을 구별하기 위해 주석에 특수 기호를 배치하는 방법을 사용할 수 있습니다. 이곳의 장점은 찾기가 쉽다는 것입니다. 6. 명령문의 변경사항은 해당 설명에 매핑됩니다. 7. 주석과 코드 사이에는 명확한 간격이 있어야 어느 것이 명령문이고 어느 것이 주석인지 한눈에 알 수 있습니다. 코드 줄 앞이나 뒤 줄에 주석을 달거나 코드 바로 뒤에 공백을 2개 이상 남겨 둘 수 있습니다. 단, 코드와 주석이 같은 줄에 있는 경우에는 주석 뒤에 코드를 넣지 마세요. 주석 뒤에 코드를 넣지 마십시오. 주석은 코드 중간에 배치됩니다.