Prefix unit local variable names

[Mike Torrettinni 198]

Just looking for some ideas how to prefix unit's local variables. In last few years I got used to these prefixes:

 

TVarType; (I just can't get used to lower case: tVarType)

fVarName - local field

gVarName - global var

vVarName - method local var

aParam - parameter

cConstName - constant

 

unit local var: I used to have LVarName, then lVarName, now I have:

xVarName, which I like, but looking for other ideas.

[David Heffernan 2345]

37 minutes ago, Mike Torrettinni said:

aParam - parameter

a is for argument 

[Mike Torrettinni 198]

1 minute ago, David Heffernan said:

a is for argument 

Aha, yes correct, thanks! I just couldn't deal with AArgName/AParamName, these capital prefixes look so out of place - I know it's personal preference, but I'm usually the only developer, so I have a little more wiggle room with namings.

[FPiette 383]

1 hour ago, Mike Torrettinni said:

but looking for other ideas.

I'll write almost as you do except:

1) First letter is always uppercase.

2) Constant have no prefix but always all uppercase with underscore to separate words like MAX_CLIENT

3) Local method variable have no prefix at all since all other have a prefix.

 

As you said, it is much of personal taste but your asked so my answer.

[Mike Torrettinni 198]

2 minutes ago, FPiette said:

3) Local method variable have no prefix at all since all other have a prefix.

That's interesting. I used to prefix fFunction and pProcedure, but I stopped as I figured out it doesn't matter to know from the name if it's function or procedure, so these have no prefixes anymore.

[Guest]

more purist, tend to use "Hungarian Notation" by  Charles Simonyi ( Xerox PARC circa 1972–1981, and who later became Chief Architect at Microsoft ) - at least in "C", or co-related! And dont changed until today in Windows APIs (at least in your tottality), then, it's a good example!

https://en.wikipedia.org/wiki/Hungarian_notation

 

As I dont speak Hungarian, or, English, I use my "lMyXXXXX" (L) in var/obj names (Global, Local, Params, etc.. ), T for types, prc/fnc for Procs/Funcs, "I" to Interfaces... ah! to for anonymous proc / func I do not use any of them! 😂

Of course, if in a "team", I would change "lMy" to "I<<company acronym>>"

 

But, I love use CTRL+D to format my code, with "{ }" end-line delimiter!

Edited December 5, 2020 by Guest

[Mike Torrettinni 198]

1 minute ago, emailx45 said:

more purist, tend to use "Hungarian Notation" by  Charles Simonyi ( Xerox PARC circa 1972–1981, and who later became Chief Architect at Microsoft )

https://en.wikipedia.org/wiki/Hungarian_notation

 

As I dont speak Hungarian, or, English, I use my "lMyXXXXX" (L) in var/obj names (Global, Local, Params, etc.. ), T for types, prc/fnc for Procs/Funcs, "I" to Interfaces... ah! to for anonymous proc / func I do not use any of them! 😂

Of course, if in a "team", I would change "lMy" to "I<<company acronym>>"

 

But, I love use CTRL+D to format my code, with "{ }" end-line delimiter!

I never liked Hungarian style, perhaps I would like it in 1972, but I wasn't born then, yet. I used to try with prefixing variables by type - no way! 🙂

 

I use GExpert's Align lines to align assignments ( :=, =,<> ) when in multiple consecutive lines,

[Guest]

I had 3 years old, and I think that is good, but Im not commercial developer, just, for hobby !

Edited December 5, 2020 by Guest

[Remy Lebeau 1398]

On 12/5/2020 at 6:09 AM, Mike Torrettinni said:

vVarName - method local var

V is more commonly used for method arguments that are declared as var, while A is for arguments that are not var.

On 12/5/2020 at 6:09 AM, Mike Torrettinni said:

unit local var: I used to have LVarName, then lVarName

L is more commonly used for method local variables, and G is more commonly used for unit local variables that are not consts.

 

[Mike Torrettinni 198]

39 minutes ago, Remy Lebeau said:

V is more commonly used for method arguments that are declared as var, while A is for arguments that are not var.

Interesting, I never noticed that, usually is A, or no prefix. I did notice a few a prefix examples, but not many.

I just checked some open source projects that I look at at time to time and I do see this, but is again capital V like : var VUserName.

 

Capital prefixes seem so old-school.

[Remy Lebeau 1398]

16 hours ago, Mike Torrettinni said:

I just checked some open source projects that I look at at time to time and I do see this, but is again capital V like : var VUserName.

Case doesn't really matter, especially in a case-insensitive language like Delphi.

16 hours ago, Mike Torrettinni said:

Capital prefixes seem so old-school.

Hungarian Notation in general is very old-school.

[David Heffernan 2345]

10 minutes ago, Remy Lebeau said:

Case doesn't really matter, especially in a case-insensitive language like Delphi.

Except the reality is that you do take care over the latter case that you use, even though the compiler ignores it. It's somewhat ironic that PascalCase is a thing if letter case doesn't matter in Pascal.

 

When you choose names, you take care over the letter case that you use, and then you try to stick to that letter case when you use that name.

 

Which to me is the clincher in why languages should be sensitive to letter case.

[Darian Miller 361]

I have switched over the years but current prefixes include

 

f for Fields

p for Parameters

v for Local Variables

You could also use v for Var parameters 

 

I no longer prefix constants - I add them to classes and scope all uses with the class name.  If I don't use class scoped constants, I slip back into old school mode and use all uppercase for unit constants.

TMyClass = class
public const
   DefaultMessage = 'Hello World';
...
ShowMessage(TMyClass.DefaultMessage)

Globals are treated similar to constants...if used, add them to a globals class or record.

 

Since I have a strong preference for lower case prefixes, I prefer v over l for local variables as the l prefix can lead to readability issues. 

 

I just don't reading:  FThreadCount, AThreadCount, LThreadCount.  I'd rather see fThreadCount, pThreadCount, vThreadCount.  I believe the prefix used for parameters and local variables is stricly for collision prevention purposes only and shouldn't be highlighted with a capital letter.

 

There are a few coding standards on the web for reference if you'd like to review: 

http://www.sourceformat.com/coding-standard-delphi-econos.htm

http://mc-computing.com/languages/delphi/Style_Guides.html

https://edn.embarcadero.com/article/10280#3.5

https://wiki.freepascal.org/Coding_style

https://www.gnu-pascal.de/h-gpcs-en.html

https://wiki.delphi-jedi.org/wiki/Project_JEDI_Delphi_Language_Style_Guide

 

 

I think we had about 8 Delphi developers on staff at my previous job when we all got together and voted on style rules.  The daily Code Reviews started enforcing those style rules.  It wasn't enforced 100% of the time but it did help standardize the code better than before.  (4+ million lines of Delphi code written by a few dozen different developers.)   These prefixes came from that vote about 12 ago now.

 

 

[Mike Torrettinni 198]

1 hour ago, Darian Miller said:

I just don't reading:  FThreadCount, AThreadCount, LThreadCount.  I'd rather see fThreadCount, pThreadCount, vThreadCount. 

I totally agree with you! Such a small thing ad makes a big difference.

 

Except for type TType, I still use T for all types. Not sure why, but probably has something to do with the fact that it start the line/name.

 

type
  TProject = ...
  tProject = ....

lower t just seems off in this case. 🙂

[Stano 143]

When I was thinking about prefixes, I was strongly advised to follow the Delphi syntax.
No prefixes and CAMEL style.
I only use A for arguments in a function or procedure.
I have no problem.

[Darian Miller 361]

36 minutes ago, Mike Torrettinni said:

Except for type TType, I still use T for all types. Not sure why, but probably has something to do with the fact that it start the line/name.

 

type
  TProject = ...
  tProject = ....

lower t just seems off in this case. 🙂

 

Type definitions are different...   

I definitely prefix with uppercase T

Except for Error class types that start with uppercase E

Interfaces with uppercase I

 

[Guest]

a good resource in RAD, at least in Delphi, is use of CTRL+D  (Format Source):

• Once the variable name or class / etc ... is defined in the unit (once the file is read from the beginning to the end - 😂 ), all other instances found in the unit will be reformatted to the same case as the first to be found.
  • this is valid to WHOLE PROJECT!  - "Project menu, Format Project Sources..." --- 4MI lines in ... take a minute... some hours...
• And you define this "Tools, Options, Language, Delphi, Formatter, Delphi, Capitalization, Capitalization of other words = As first occurrence" - I like this!

Edited December 8, 2020 by Guest

[Guest]

5 hours ago, Darian Miller said:

I have switched over the years but current prefixes include

...

I think we had about 8 Delphi developers on staff at my previous job when we all got together and voted on style rules.  The daily Code Reviews started enforcing those style rules.  It wasn't enforced 100% of the time but it did help standardize the code better than before.  (4+ million lines of Delphi code written by a few dozen different developers.)   These prefixes came from that vote about 12 ago now.

• You could hire someone to stay all day using CTRL + D, using the group's rules!  😂

[Guest]

I am unemployed in this pandemic period!  

[FPiette 383]

This discussion is endless. Each developer has his own preferences. There is no absolute best way to format code.

 

IMO the only important thing is to have a consistent set of rules and to apply it strictly, especially for a team of developers. Everyone has to do the same so that each person can read the code the others wrote. There is always someone that will not like your set of rules...

 

If you get code from elsewhere, you can reformat it using Delphi code format tool which is configurable with lot's of rules. This tools can do almost my own rules only some alignments are missing and I can survive.

[Mike Torrettinni 198]

Someone must have felt really good writing this statement: Delphi is created in California, so we discourage the use of hungarian notation, except where required in header translations ... 🙂

(in https://wiki.delphi-jedi.org/wiki/Project_JEDI_Delphi_Language_Style_Guide)

 

There's actually an SO question about it: https://stackoverflow.com/questions/18583756/what-is-meant-by-delphi-is-created-in-california-so-we-discourage-the-use-of-n 🙂 🙂

 

Seems like everybody coming up with their own naming conventions are really proud of their work. Which is pretty cool as many developers rely on their set of rules. I had no idea this was such a big and important topic in Delphi! 🙂

[Guest]

hi Mike,

 

this is the human-nature!

"...not happy with first place, he starts a new race to overcome himself!"

a "ego trip"!

Edited December 8, 2020 by Guest

[Mike Torrettinni 198]

3 minutes ago, emailx45 said:

hi Mike,

 

this is the human-nature!

"...not happy with first place, he starts a new race to overcome himself!"

a "ego trip"!

🙂

 

Ego <> smart!

 

[dummzeuch 1505]

38 minutes ago, Mike Torrettinni said:

🙂

 

Ego <> smart!

 

For me "Ego = smart", but your mileage might vary. 😉

[Guest]

when the ego emerges to awaken the intelligence and put it to produce a better human being in his actions with his neighbor, then, we can say that there is something intelligent there. Otherwise, what will emerge will only be arrogant arrogance and intolerance towards what is different.