Variables, fields, arguments and properties naming

Pascal
1

Good day! :upside_down_face:
I want to do refactoring of the some classes in my code. And in the one hand I like idea to use for the all class fields prefix “F” and for all procedures arguments prefix “A”.
It seems useful, when I want to set fields, for example:

procedure TInanimate.SetInanimate(AName, AUrl : String);
begin
  FName := AName;
  FIconUrl := AUrl;
end;

And I like having a standard for naming fields regardless of whether there is a property for that field.
But in the second hand this seems little ugly. And, as I see, this is not very common practice in the CGE examples…
I think it is not only the a matter of taste, but way to make code some better. So, what naming you like, what you recommend and use? And what names you like for the properties, if you not use Fxxx fields names?
Thanks!

2

I think I have the same feelings as you (consistency is good, but also “A for all params and F for all fields” looks a bit ugly). I haven’t really “resolved” these feelings with 100% strict rules in my head, after more than 20 years of coding in Pascal :slight_smile:

So, my general rule of working:

  • Private fields get F prefix always, which means: field FXxx backs a property Xxx.

  • Parameters get A prefix (or An, like AnItem, following English rules) if it is really necessary, which means: they would otherwise conflict with field/property name.

… but I don’t treat these 2 conditions (“… always …” for fields, “… if it is really necessary …” for params) strictly. So you will find throughout CGE deviations from these rules:

  • occasional code where I didn’t use F prefix for private fields. Maybe the class has lots of private fields, not backed by properties.
  • occasional code where I used A / An prefix for parameters even though it is not strictly implied by the above rule. Maybe it was historically necessary.

Somehow it works for me :slight_smile:

Important factor here is that both these decisions are about internal things – i.e. the prefix F is only for private fields, or A for parameters of routines. None of these things determine the public API of Castle Game Engine. E.g. public fields, if ever, in CGE look just like properties (and may change into properties at any point), never have F prefix.

So, I guess I don’t feel very bad about being a bit inconsistent in applying these prefixes, because I know I can always change it – without affecting CGE users at all. There is a fear that it will cause trouble for contributors (this would be a reason to make these rules more strict, and also document in Coding Conventions | Manual | Castle Game Engine ) – but so far, it seems all contributors picked up this rule and follow it, 90% consistently, just like me :slight_smile: So it works.

As always, this is just “what I do” (and I guess it determines CGE source code).

I think LCL code is a bit similar, but maybe more strict in following these rules:

In above (~random 3 unis from LCL), LCL seems to follow similar rule as me for A param prefix (so some params have it, some don’t) but more strict rule for F private fields prefix (it seems 100% of their private fields have it).

Opinions / thoughts / alternative approaches are welcome :slight_smile:

1 Like