Object Pascal Style Guide

Abstract:This article documents a standard style for formatting Delphi code. It is based on the conventions developed by the Delphi team.

Object Pascal Style Guide

This article documents a standard style for formatting Delphi code. It is based on the conventions developed by the Delphi team.

We take it for granted that many well established shops will have conventions different than those specified here. As a result, we strongly recommend using a tool that can convert your code into Borland style before submitting it to Borland, Project JEDI, or any other public source repository. We don''''t want to force you to change your conventions, but we insist that all code that ships with Borland products follows these conventions. We strongly encourage you to follow these conventions when submitting code into any form of public repository.

Object Pascal is a beautifully designed language. One of its great virtues is its readability. These standards are designed to enhance that readability of Object Pascal code. When developers follow the simple conventions laid out in this guide, they will be promoting standards that benefit all Delphi developers by using a uniform style that is easy to read. Efforts to enforce these standards will increase the value of a developer''''s source code, particularly during maintenance and debugging cycles.

It goes without saying that these are conventions based primarily on matters of taste. Though we believe in, and admire the style promoted in these pages, we support them not necessarily because we believe they are right and others are wrong, but because we believe in the efficacy of having a standard which most developers follow. The human mind adapts to standards, and finds ways to quickly recognize familiar patterns, thereby assimilating meaning quickly and effortlessly. It is the desire to create a standard that will make reading code as simple as possible for the largest number of people that is behind this effort. If at first our guidelines seem strange to you, we ask you to try them for awhile, and then we are sure you will grow used to them over time. Or, if you prefer, keep your code in your own format, and run it through a program that follows our guidelines before submitting it to Borland or to a public repository.

Some text editors, such as Visual SlickEdit can help you format your code according to a particular style. Readers who are aware of other tools that provide this same service should write me at that address provided at the end of this section.

One free formatter developed by Egbert van Nes is available at the following URL:
http://www.slm.wau.nl/wkao/delforexp.html.

A commercial option is CrackerJax for Delphi:
http://www.kineticsoftware.com/html/products.html.

Before closing this introduction, I want to reiterate that on the Borland web site, and on the CDs that we ship with our product, these standards are the law. We want to present our code in a unified and easy to read style, and enforcing the rules in this guide is the simplest way to achieve that end.

Do not post this specification on other web sites. Instead, simply link to this version of the document.

We accept feedback in the form of corrections or suggestions. Send your communications to Charlie Calvert .

Contents

• 1.0 Introduction
  • 1.1 Background
  • 1.2 Acknowledgments

• 2.0 Source Files
  • 2.1 Source-File Naming
  • 2.2 Source-File Organization
    • 2.2.1 Copyright/ID block comment
    • 2.2.2 unit declaration
    • 2.2.3 uses declarations
    • 2.2.4 class/interface declarations

• 3.0 Naming Conventions
  • 3.1 Unit Naming
  • 3.2 Class/Interface Naming
  • 3.3 Field Naming
  • 3.4 Method Naming
  • 3.5 Local Variable Naming
  • 3.6 Reserved Words
  • 3.7 Type Declarations

• 4.0 White Space Usage
  • 4.1 Blank Lines
  • 4.2 Blank Spaces
    • 4.2.1 A single blank space (not tab) should be used:
    • 4.2.2 Blanks should not be used:
  • 4.3 Indentation
  • 4.4 Continuation Lines

• 5.0 Comments
  • 5.1 Block Comments
  • 5.2 Single-Line Comments

• 6.0 Classes
  • 6.1 Class Body Organization
  • 6.2 Method Declarations
  • 6.3 Data Store Declarations

• 7.0 Interfaces
  • 7.1 Interface Body Organization

• 8.0 Statements
  • 8.1 Simple Statements
    • 8.1.1 Assignment and expression statements
    • 8.1.2 Local variable declarations
    • 8.1.3 Array declarations
  • 8.2 Compound Statements
    • 8.2.3 if statement
    • 8.2.4 for statement
    • 8.2.5 while statement
    • 8.2.6 repeat until statement
    • 8.2.7 case statement
    • 8.2.8 try statement

  1.0 Introduction

  This document is not an attempt to define a grammar for the Object Pascal language. For instance, it is illegal to place a semicolon before an else statement; the compiler simply won''''t let you do it. As a result, I do not lay that rule out in this style guide. This document is meant to define the proper course of action in places where the language gives you a choice. I usually remain mute on matters that can only be handled one way.

  1.1 Background

  The guidelines presented here are based on the public portions of the Delphi source. The Delphi source should follow these guidelines precisely. If you find cases where the source varies from these guidelines, then these guidelines, and not the errant source code, should be considered your standard. Nevertheless, you should use the source as a supplement to these guidelines, at least so far as it can help you get a general feel for how your code should look.

  1.2 Acknowledgments

  The format of this document and some of its language is based on work done to define a style standard for the Java language. Java has had no influence on the rules for formatting Object Pascal source, but documents found on the Sun web site formed the basis for this document. In particular the style and format of this document were heavily influenced by "A Coding Style Guide for Java WorkShop and Java Studio Programming" by Achut Reddy. That document can be found at the following URL: http://www.sun.com/workshop/java/wp-coding

  The Delphi team also contributed heavily to the generation of this document, and indeed, it would not have been possible to create it without their help.

  2.0 Source Files

  Object Pascal source is divided up primarily into units and Delphi Project files, which both follow the same conventions. A Delphi Project file has a DPR extension. It is the main source file for a project. Any units used in the project will have a PAS extension. Additional files, such as batch files, html files, or DLLs, may play a role in a project, but this paper only treats the formatting of DPR and PAS files.

  2.1 Source-File Naming

  Object Pascal supports long file names. If you are appending several words to create a single name, then it is best to use capital letters for each word in the name: MyFile.pas. This is known as InfixCaps, or Camel Caps. Extensions should be in lower case. For historical reasons, the Delphi source itself often confines itself to 8:3 naming patterns, but developers no longer need feel constrained by those limits, even if turning in source that might be used by the Delphi team.

  If you are translating a C/C++ header file, then your Pascal header translation will usually have the same name as the file you are translating, except it should have a PAS extension. For instance, Windows.h would become Windows.pas. If the rules of Pascal grammar force you to combine multiple header files into a single unit, then use the name of the base unit into which you are folding the other files. For instance, if you fold WinBase.h into Windows.h, then call the resulting file Windows.pas.

  2.2 Source-File Organization

  All Object Pascal units should contain the following elements in the following order:
  1. Copyright/ID block comment
  2. Unit Name
  3. Interface section
  4. Implementation
  5. A closing end and a period.

  At least one blank line should separate each of these elements.

  Additional elements can be structured in the order you find most appropriate, except that the top of the file should always list the copyright first, the unit name second, then any conditional defines, compiler directives or include statements, then the uses clause:

  {*******************************************************}
  {                                                       }
  {       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;
  

  It does not matter if you place a type section before a const section, or if you mix type and const sections up in any order you choose.

  The implementation should list the word implementation first, then the uses clause, then any include statements or other directives:

  implementation
      
  uses 
    Consts, SysUtils, ActnList, 
    ImgList;
      
  {$R BUTTONS.RES}
  

  2.2.1 Copyright/ID block c

  [1] [2] [3] [4]  下一页

  
  [系统软件]14.5.10.1 Object creation expressions  [VB.NET程序]VB.Net中文教程(8)  对象(Object)基本概念
  [Delphi程序]The Delphi Object Model (PART III)  [Delphi程序]The Delphi Object Model (PART II)
  [Delphi程序]The Delphi Object Model (PART I)  [Delphi程序]Object Pascal：从对象指针谈起
  [Delphi程序]浅谈Object Pascal的指针  [Delphi程序]kmp模式匹配算法的pascal实现
  [Delphi程序]Object TreeView简要说明  [Delphi程序]Pascal 精要--第一章
  

Copyright ＠ 2007-2012 敏韬网(敏而好学，文韬武略--MinTao.Net)（学习笔记） Inc All Rights Reserved.
闵涛 E_mail:admin@mintao.net(欢迎提供学习资源)

鄂公网安备 42011102001154号

站长：MinTao ICP备案号：鄂ICP备11006601号-18