So I go by this Delphi naming scheme of arguments start with A, class vars start with F and local vars start with M. Does that scheme have a name? I see it a lot in the Delphi source I'd like to read more about it but I'm not sure what it's called.
+6
A:
In general, that sounds like Hungarian notation - but that doesn't specify the A, F or M convention, specifically, just the prepending of type information into the name.
Yishai
2009-07-16 21:58:14
I thought hungarian put type and content information in there--like piVar if var is a pointer to an int and also specified a set of values to use. I mean I thought it was more specific than just "prefixing" but I could be wrong.
Bill K
2009-07-16 21:59:58
Hungarian notation can be done in different ways, but as a general rule putting language specific information in the variable name is called Hungarian notation. Joel famously argues that it should be used differently altogether, but regardless of how it "should" be, this is what people call it. http://www.joelonsoftware.com/articles/Wrong.html
Yishai
2009-07-16 22:10:20
Then again, Delphi's type system makes the problems that Joel's "good Hungarian" solves obsolete. If you want a special type of integer or string that isn't assignment-compatible with normal integers or strings, you can declare one by using the "type" keyword inside the type definition, and have the compiler catch these errors for you.
Mason Wheeler
2009-07-16 22:43:58
No, Mason, those are still assignment-compatible. For example, you can assign a Double to a TDateTime and vice versa, despite their being two distinct types. Likewise for AnsiString and Utf8String in Delphi 7-2007. What you're *not* allowed to do is pass one type to a function as a `var` parameter when another type is expected.
Rob Kennedy
2009-07-16 23:29:30
+9
A:
Your schema can be considered some form of Hungarian notations (HN). Usually HN is used to signify the type of a variable, but as Wikipedia notes,
The notation is sometimes extended in C++ to include the scope of a variable, separated by an underscore. This extension is often also used without the Hungarian type-specification: [..]
Stephan202
2009-07-16 22:02:53
+6
A:
I would say your naming convention doesn't really match the Hungarian Notation, but it tends a bit to be closer to the original Hungarian Notation invented by Charles Simonyi which came to be known as Apps Hungarian. But not quite.
There are actually two types of Hungarian Notation:
- Apps Hungarian - the idea was to decorate identifiers names based upon the semantic information of what they store, so basically the variable's purpose:
rwElement - variable represents a row ("rw")
colElement - variable represents a columns ("col")
- Systems Hungarian - the prefix encodes the actual datatype of the variable.
szName - variable is a zero-terminated string ("sz")
lAccount - variable is a long integer ("l")
So while you naming convention does in a way represent some sort of purpose, it's not really the purpose that Apps Hungarian refers to.
Mircea Grelus
2009-07-16 22:30:13
He's using a form of Hungarian which indicates scope. I wouldn't say that is any closer to purpose than it is to datatype.
Kevin Peterson
2009-07-16 22:33:06
My rationale was that it's nowhere near a datatype, but scope when designing the app has a purpose. It's not the same purpose of course, but out of the two, it is closer to being like that for a purpose.
Mircea Grelus
2009-07-16 22:42:28
+3
A:
Yours is in the general class of naming conventions known as Hungarian notation (in the perhaps broader-than-usual sense that the name has a prefix describing the variable), but no, your convention doesn't have any more specific name.
I've never seen your particular choice of prefixes before. The closest I've seen is what I think of as the Indy convention, which uses A for arguments, F for fields, G for globals, L for locals, and of course the usual I for interfaces and T for records and classes. Properties and subroutines get no prefix.
Rob Kennedy
2009-07-16 23:39:15
Did you just make that name up from the correlation between the Delphi RTL and Indy Source or did Borland Programmer actually pick that stuff up from Indy guys in the early days of Delphi? I don't have any source earlier than Delphi 7 so I can't see a difference.
Peter Turner
2009-07-17 13:48:33
The `F`, `I`, and `T` prefixes are used near-universally, and the `A` prefix is very common. Use of prefixes on globals and locals is something I most associate with Indy; I'm not aware of any `G` or `L` prefixes in the Borland code.
Rob Kennedy
2009-07-17 14:09:54
+11
A:
This coding style is specifically called out in the Object Pascal Style Guide as not being Hungarian notation (with one exception, enumerated types.)
The specific coding conventions you're talking about don't have a name as such, as far as I know, it's simply that you're writing code conforming to the CodeGear (old Borland) coding style guide. The guide doesn't seem to give the style a name.
The reason you see it a lot in the Delphi source is because this guide is based on the coding style the Delphi team developed!
This document's well worth reading - not only for code guidelines but also out of interest for other things it mentions.
David M
2009-07-17 00:03:33
WTF? why was this voted down? This IMO is the best answer, its certainly the most correct. In fact I removed my answer because this one is better.
Tim Jarvis
2009-07-17 00:22:58
heh heh, they really need to remove Charlie Calvert's old Borland email address from that doc. Charlie now works for Microsoft.
Tim Jarvis
2009-07-17 00:27:34
Although the answer is a great answer (and I upvoted it), for giving the reference to where the style comes from, the document as I read it *did* call it Hungarian notation when it says: "The exception to the Hungarian notation rule is in enumerated types." i.e. the regular F convention is hungarian notation.
Yishai
2009-07-17 01:44:13
Thanks for the comment, Yishai. To clarify what I wrote, I read it differently - it says "we discourage the use of notation, except where required in header translations" and gives a "correct" example as "FMyString: string;" and "incorrect" as "lpstrMyString: string;". I think "lpstr" is the Hungarian notation prefix and "F" is not, by their definitions. Enumerations are the exception because they are prefixed with characters indicating the type of enumeration, eg "bkOk" for "Button Kind". Really this is an issue of semantics, it is arguable scope specifiers are Hungarian I suppose :)
David M
2009-07-17 03:21:35
I guess "by their definition" is the key here - I personally prefix my variables with scope specifiers but don't think of it as Hungarian, because it indicates neither type (int32, char*) nor usage (number, string).
David M
2009-07-17 03:26:31
Just that F is not used for global variables, but for private class property variables.
Ralph Rickenbach
2009-07-17 07:15:47
David is right. The "Hungarian notation rule" refers to the rule *discouraging* use of Hungarian notation, so the exception is for naming enum values, which *do* use Hungarian. But it's worth pointing out that the OP style guide says *nothing* about naming arguments, and it says that locals use the same rules as field names, sans the leading `F` — so no `M` or `L`. At best, Peter's style is a *derivative* of the OP style, just like all Delphi coding styles, but I really think a closer relative is the Indy style, which uses more prefixes.
Rob Kennedy
2009-07-17 15:06:14