![]() |
![]() |
|
![]() |
TIP:PdoxWin:Suggested ObjectPAL Naming Convention:2000.03.25 Version 1.0 (2000.03.25) edited by Paradox FAQ Team Reposted by Mike Irwin: 2001.02.10 ==================== 0. Introduction ==================== This FAQ offers a suggested naming convention for use by ObjectPAL programmers. It is obviously not the only possible convention, and suggestions for improvements are gladly solicited. ------------------------------- 0.1 Legal Info and Disclaimers ------------------------------- Paradox is a trademark of Corel. Borland Database Engine (BDE) is a trademark of Inprise. The information provided in this FAQ is provided "as is" and is not warranted in any way. The information provided in this FAQ is not endorsed or authorized by Corel or Inprise in any shape, form, or manner. The editors claim NO responsibility for ANY illegal activity regarding this file, or as a result of someone reading this file. You may distribute this file, as long as the copies are complete, unaltered, and are in electronic form only. ------------- 0.2 Feedback ------------- Please send feedback in a Corel Paradox newsgroup or the news:comp.databases.Paradox newsgroup to any of the FAQ Team mentioned in the "FAQ: FAQ FAQ" document. Please preface the subject of your post with the string "PDXWIN FAQ" to alert Team members to the function of the message. Please specify the FAQ name and section number the comment applies to, if any. ============================== 1. General Information ============================== This convention dates back to a meeting held at DataStar in New Jersey in early 1994, where the issue of presenting our code in a coherent fashion was discussed. The background to this was the need to be able to understand each others' code when we worked together on projects, and also the need to present an understandable framework to our trainee clients. ======== 2. Basics ======== We decided on prefix (or "reverse hungarian" - for Microsoft's Charles Simonyi) as opposed to postfix notation, as many people with a C and VB background were using ObjectPAL. We decided that, so far as possible, two letters only would denote a normal, commonly-used, variable, and three letters be used to indicate anything else. ========== 3. Alphabetical List of Types, with prefixes. ========== A AddinForm aif ActionEvent ev AnyType at Application ap Array ar B Binary bi C Currency cu D Database db DataTransfer dtr Date da DateTime dt DDE dde DynArray dy E ErrorEvent ev Event ev F FileSystem fs Form fo G Graphic gr H-K KeyEvent ev L Library None. Use the full library name as variable name Logical lo LongInt li M Mail ma Memo mm Menu me MenuEvent ev MouseEvent ev MoveEvent ev N Number nu O OLE ole OleAuto ola P Point pt PopUpMenu pm Q Query qu R Record rd Report re S Script sc Session se SmallInt si SQL sql StatusEvent ev String st System sy T Table ta TableView tv TCursor tc TextStream ts Time ti TimerEvent te Toolbar tb U UIObject ui V-Z ValueEvent ev ========== 4. Exceptions and Additions, with reasons ========== 1. Because of the particular syntax of libraries, we decided to omit a prefix completely, and standardise on naming them so that the names were descriptive and then using the full name as the variable name. 2. SQL and DDE variables came late to ObjectPAL, so use "sql" and "dde", respectively. 3. There's no obvious way of telling the type of the element of an array, so we standardised on appending the type prefix to the array prefix. While clumsy, it makes things perfectly clear, as you can see in this example of breaking a string into parts, where arstBits is an array of strings to hold the bits of the string stPath: stPath.breakApart(arstBits, "\\") 4. Form-global items. Normally, variables are transient, local to the code that uses them. However, some variables need to be globally available. To make it easy to see which ones these are, add a "G" to the prefix, no matter what the prefix is. Obviously, this applies within libraries and scripts too. One commonly-seen global variable is foGMySelf, declared in the Var section of #formdata1 as foGMySelf Form and asssigned in #formdata1.open() as: foGMySelf.attach() 5. Methods. Normally prefix a method "cm", for "common method". However, prefix it "em" if it is intended to be used externally. 6. Object Variables. Any variable that links to an object should be given the name of that object. Thus a tCursor to a table called "Fred.db" gets the name tcFred. This makes approximately an order of magnitude difference in code comprehension. Do not use the same variable for multiple things ! 7. TableFrames and Multi-Record Objects. These will normally be automatically assigned a name identical to the table they present to the user. In early versions of Paradox for Windows these names were always uppercase- only. Continuing to use this standard can clarify code considerably, as in: tcSchedule.attach(SCHEDULE) ;attach tCursor to MRO If you have any additions that feel would be useful, please contact Mike Irwin at michealirwin@home.com Paradox Community Newsgroups |
![]() Feedback | Paradox Day | Who Uses Paradox | I Use Paradox | Downloads ![]() |
|
![]() The information provided on this Web site is not in any way sponsored or endorsed by Corel Corporation. Paradox is a registered trademark of Corel Corporation. ![]() |
|
![]() Modified: 15 May 2003 Terms of Use / Legal Disclaimer ![]() |
![]() Copyright © 2001- 2003 Paradox Community. All rights reserved. Company and product names are trademarks or registered trademarks of their respective companies. Authors hold the copyrights to their own works. Please contact the author of any article for details. ![]() |
![]() |
|