I have often wondered why the "A" prefix is used on Delphi parameters. Instead of just accepting it as some esoteric thing as I have done for the past twenty years, I googled around and found an answer. Have a look at the following code snippet:
constructor TPerson.Create(AFirstName, ALastName: string); begin FirstName := AFirstName; LastName := ALastName; end;The "A" in "AFirstName" and "ALastName" denotes an Argument as in the above constructor code example.
Typical naming conventions that are used are:
A := Argument F := Field T := Type E := Exception I := Interface L := Local Variable G := Global VariableThe key is to be consistent in all your code. If we as a Delphi community are consistent then it makes it much easier to communicate with each other.
See also:
Object Pascal Style Guide By: Charles Calvert
[Archive]
#delphi #tipoftheday #capecodgunny
Enjoy,
Gunny Mike
https://zilchworks.com
You're right: it is very important to have a consistent code style in the community, but that won't ever happen. They all claim to write the "cleanest" code with their custom code style (all are different, and all are ugly, sorry). There was once a nice document on how to format the Delphi code (I think it was while the Borland era), and was adopted on most VCL parts. This is what I want to see as the standard in the community. And no, sorry, using a prefix with ALL variables is ugly, too. the "A" was introduced because of the name clash - like you've written, but if you'd inspect the older VCL-code (the newer one is mostly written by those not obeying the standard and using their own ugly style) you'd see a consistent code style. Push this style, do not make your own and claim it to be the best standard. Just use the one already here. https://xkcd.com/927/
ReplyDeleteThat is the style guide written by Charles Calvert. It was refined a little later by Stefan Hoffmeister (at econos.de). That was in the Delphi 6 timeframe, so a long time ago. I have it here, if anyone likes it. It is the style guide I still follow and which is also followed at Embarcadero. Just take a look at the RTL/VCL/etc. code.
DeleteDear Rudy Velthuis,
DeletePls be so kind to share the link on your website.
Thank you
http://edn.embarcadero.com/article/10280
Delete"Never wrap a line between a parameter and its type" - too bad the IDEs code formatting ignores this all the time.
DeleteThat guide does not mention anything about prefixing arguments/parameters and local or global variables though. I remember the more extensive borland style guide does though.
Delete@Stefan: I have the same text as an old download, and that doesn't mention arguments or prefixes for local variables either. And AFAIR, this was never revised. But there may be derived style guides, e.g. the one by Stefan Hoffmeister.
Delete@Stefan: the notiona that you prefix local or global variables came mich later and was never official Borland/Inprise/CodeGear/Embarcadero policy. The A prefix was explained once, somewhere, but never in a style guide, IIRC. FWIW, another copy: https://gist.github.com/tuksik/6ef9d4b75ee759c29d06
DeleteWay more important than sticking to a specific style guide (and at least be consistent in your code about it) is how to name things. Giving classes, methods and variables bad (not accurate, misleading) names is worse than writing them with a leading capital letter or not.
ReplyDeleteWhile naming tings properly is certainly important, a bad style can certainly make reading harder. So style guides are important too.
ReplyDeleteYou forgot 'const' qualifier for your string parameters:
ReplyDeleteconstructor TPerson.Create(const AFirstName, ALastName: string);
Always keep in mind the performance of the code you are writing.
IMHO that "const"-string is something the compiler should make it by itself. I don't see any reason why it couldn't be made automatically (I know it currently isn't).
DeleteIn my experience, a common coding glitch that gets _me_ in trouble once in a while even now, is neglecting to declare a parameter *VAR* when it needs to be.
DeleteI treat the "const" parameter qualifier as more like a statement of intent, you're saying you have no intention of altering the value of the parameter within the body of the routine.
DeleteThat the compiler can then back you up by throwing an error if you _do_ try to change the value, is useful, but actually incidental.
I've been coding in one or another dialect of Pascal (mostly the Borlandish ones) for going on 30 years. And I've experimented with a variety of formatting styles.
ReplyDeleteI've lately been writing a lot of SQL code, which has its own conventions, some of which I find nigh unreadable.
As for Delphi/Pascal code, I have a few of my own quirks, but mostly follow the style I learned at TurboPower, which was itself mostly informed by the published Borland standard.
Except for the T for types and I for interfaces which are pretty sacrosanct, we really didn't follow any prefixing standard.
Still sometimes run into code (I expect often translated from older C/C++ code) with "Hungarian Notation" prefixing, which is pretty monstrous.