First of all, let me make it perfectly clear that I dont speak Hungarian. I did eat in a Hungarian restaurant once (the food was excellent), where I heard some Hungarian -- I guess it was Hungarian -- spoken. But thats about as far as it goes.

Hungarian notation is a technique used to make the data type of a variable clear, just from the name of the variable. This is accomplished by prepending one or more characters to the variable name. The prepended characters serve as a "code" signifying the data type. Examples of this as seen in the Windows API code are h for Handle, dc for Device Context, and psz for a pointer to a zero-terminated string. Hungarian notation is called such because its originator, Microsoft's Charles Simonyi, is from Hungary.

In Pascal, it is already common practice to name an integer data type that will be used as a counter (in a for loop for instance) i. By the same token (no pun intended) it is common to name a general-purpose or temporary string type s. This is a form of Hungarian notation - albeit an extremely succinct form of it.

As data types differ among languages, I propose that Delphi programmers adopt an Object Pascal-specific form of Hungarian notation. I am not Hungarian, so I propose that we name this derivative of Hungarian notation SCIPI (pronounced "Skippy," like the peanut butter) notation. I advocate SCIPI because I am primarily Swiss, Cherokee, Italian, Portuguese, and Irish.

If youre still with me, here are the proposed data type "codes" to prepend to our variables when using SCIPI notation:

As for components, you could name them according to the list in Mark Ostroffs article "Whats in a Name" from the January 1997 issue of Delphi Informant. Or use Chapter 6 ("Coding Standards Document") in Delphi X Developers Guide by Steve Teixeria and Xavier Pacheco.

For example, if you were going to declare a TEdit and a TQuery, you would do it this way:

var
  edt: TEdit;
  qry: TQuery;

If you are declaring more than one of a particular type of component within the same scope, you can append a more descriptive part to the name. For example, if you were going to create two TIBQuery components, you might do it this way:

var
  IBqryVBTollhaus: TIBQuery; { movin in }
  IBqryBDTollroad: TIBQuery; { motorin on }

The same principle holds true for nonvisual objects, such as sl for TStringList, ms for TMemoryStream, and so on.

To make things crystal clear (or should I say "ReportBuilder clear"?), here are some examples of how you might use SCIPI notation:

unit ChoosyCodersChooseSCIPI;

interface

uses
  SysUtils, Windows, Messages, Classes, Graphics, Controls, 
  Forms, . . .;

type
  TMainForm = class(TForm)
    . . .    
  private
    procedure OpenAGIFInAJiffyUsingSCIPI;
    . . .
  end;

var
  MainForm: TMainForm;
  pgslCurrentUsers: TStrings; { instantiate TStringList }

implementation

uses
  SCIPIAbout,
  SCIPIConsts,
  SCIPIUtils;

{$R *.DFM}

ugbSortOrderAsc: Boolean;

procedure TMainForm.OpenAGIFInAJiffyUsingSCIPI;
var
  pCopyBuffer: Pointer; 
  iBytesCopied: Longint;
  iSource, iDest: Integer; 
  iLen: Integer;
  fnDestination: TFileName; 
  sDestination: String;
  sr: TSearchRec;
  iFileAttr: Integer;
  achFileName, achParams, achDir: array[0..79] of Char;
. . .

Using SCIPI notation, you no longer have to refer to the declaration of a variable to see if the variable you want to read from or assign to is a string, an integer, or something else entirely. Its as if all your variables are wearing name tags -- at a glance you can tell who they are and what you can expect from them.

Ultimately, using a naming system such as this saves time and prevents unnecessary aggravation -- something all of us could stand to have more and less of.

Clay Shannon doesnt know if he is a programmer who also happens to be a writer, or vice versa. He is the author of The Tomes of Delphi: Developers Guide to Troubleshooting (Wordware 2001) and also the novel Twisted Roads, which features a Delphi developer as one of the main characters. Clay has just finished his latest novel, entitled The Resurrection of Samuel Clemens, set in the year 2061. You can contact him at BClayShannon@aol.com.