A book about Object Pascal Style Guide

[Uwe Raabe 2057]

Of course, everyone has its own take on these things. Most preferences just came out of habits. You like what you do and everything else looks strange. That doesn't make one superior to the other if taken out of your own perception.

 

I'm still proposing the original style guide now available in a newer form: Delphi’s Object Pascal Style Guide. Not because it is superior or more readable. A big advantage is that I don't have to switch mentally when looking at the Delphi sources (although they don't even adhere to it everywhere) and my own sources.

 

That said, a style guide is something a team has to agree on and follow it. While this can vary from team to team, it is not a strict law that has to be enforced. That's why it is called Guide instead of Rails.

 

At the end, style guides evolve as Marco perfectly states in his article New Delphi’s Object Pascal Style Guide:

Quote

None of these guidelines is set in stone and we expect them to evolve over time along with the language.

 

[toms 29]

I would stick to the notation of the Delphi sources rather than using others.

[Mike Torrettinni 198]

5 minutes ago, toms said:

I would stick to the notation of the Delphi sources rather than using others.

There's quite a lot of inconsistency in Delphi sources, in some cases very obvious when a different developer implemented a change and introduced new variables. Completely different style, or usage of L prefix.

[Uwe Raabe 2057]

4 minutes ago, Mike Torrettinni said:

There's quite a lot of inconsistency in Delphi sources

Indeed there is. That has probably been the trigger to revamp the old style guide to support the newer language features and establish it inside the developer team at Embarcadero. I hope we can expect more consistency here in the future.

 

That doesn't invalidate the argument, though. The standard style is widely spread and most developers are quite proficient to read it. A lot of style guides in the wild are more or less small variations (if at all) of this standard. You won't ever surprise any developer presented with sources following this style. That somehow makes it unique and means it has an advantage.

[David Heffernan 2345]

I have to say that I have never understood why args get prefixed with A and why local variables get prefixed with L. Upper or lower case. I just don't see the benefit.

[Mike Torrettinni 198]

24 minutes ago, Uwe Raabe said:

Indeed there is. That has probably been the trigger to revamp the old style guide to support the newer language features and establish it inside the developer team at Embarcadero. I hope we can expect more consistency here in the future.

 

That doesn't invalidate the argument, though. The standard style is widely spread and most developers are quite proficient to read it. A lot of style guides in the wild are more or less small variations (if at all) of this standard. You won't ever surprise any developer presented with sources following this style. That somehow makes it unique and means it has an advantage.

Well, it is true that I'm still looking at 10.2 sources, so perhaps 11 or future versions will improve, but I seriously doubt they will put resources into restyling current code over bug fixes. I hope not.

[Stano 143]

35 minutes ago, David Heffernan said:

I have to say that I have never understood why args get prefixed with A and why local variables get prefixed with L. Upper or lower case. I just don't see the benefit.

Personally, I only use it if the name of the argument matches another name. Unfortunately, Pascal Analyzer found me such matches  very more.
I'd rather be without them.

Edited February 23, 2022 by Stano

[Anders Melander 1783]

56 minutes ago, David Heffernan said:

I have to say that I have never understood why args get prefixed with A

I'm sure you understand why.

procedure TFooBar.SetValue(const AValue: TFooFoo);
begin
  var Value := AValue.Transform;
  FValue := Value;
end;

Did you mean that there are better solutions? Sure there is but I think this is a case of preferring good enough over perfect.

[Uwe Raabe 2057]

@Anders Melander Assuming the property backed by FValue is also called Value, the name of the local variable seems to be a bit questionable. TransformedValue looks appropriate.

 

Then the parameter may indeed be named Value, even if that clashes with the property name. We often have these name clashes that only work because of scope. This could be one of the situations I would tend to actually accept it.

 

At least I rate it much better than fighting with case sensitivity.

 

Could it be we strive a bit off topic here?

[Anders Melander 1783]

2 minutes ago, Uwe Raabe said:

Assuming the property backed by FValue is also called Value

What property? 🙂

 

3 minutes ago, Uwe Raabe said:

Could it be we strive a bit off topic here?

Sure but isn't that topic stone dead by now? The OP has taken his ball and gone home and that's the end of that.

[David Heffernan 2345]

33 minutes ago, Anders Melander said:

I'm sure you understand why.

procedure TFooBar.SetValue(const AValue: TFooFoo);
begin
  var Value := AValue.Transform;
  FValue := Value;
end;

Did you mean that there are better solutions? Sure there is but I think this is a case of preferring good enough over perfect.

Sure, if you decide that all things must be called "value", then life is tough. But why make things so difficult? 

[timfrost 78]

Some of the comments to https://softwareengineering.stackexchange.com/questions/196706/creating-a-coding-standards-document may be relevant.  I read into several of them that the best advice is often, "don't try this".

[Lars Fosdal 1792]

OP deleted both the sourceforge content and his account here. Go figure.

[toms 29]

16 hours ago, Stano said:

Here is a modified version of docx. I didn't do anything with the content. Only with formatting.
It was totally broken. If you use it, you do not change the styles used in any way. You break the whole document.
This file can be found if you would like to do the translation. I did the translation into Slovak. I just haven't checked it yet.
Unfortunately, I did the formatting twice. First for Slovak and then the original

Object Pascal Style Guide - Developers Guide EN.docx

 

There's something messed up in the docx, E.g. missing spaces between words. Compare the pdf with docx:

Edited February 23, 2022 by toms

[Stano 143]

Toto sa tiahne celým textom. Skontroloval som to len s kódom. pozriem sa na to.

If it weren't for PDF, I wouldn't put it together

Edited February 23, 2022 by Stano

[Stano 143]

I turned on grammar checking. I fixed, all the reds, I knew.
It seems to me that there is a mixture of American and English English. Plus something Danish here and there.
I don't know English. So the rest is up to another volunteer.

Object Pascal Style Guide - Developers Guide EN.docx

[toms 29]

Update:

• A lot of missing spaces inserted
• Some Br. -> Am. English to make it consistent
• Some grammatical errors corrected

Object Pascal Style Guide - Developers Guide EN.pdf

Object Pascal Style Guide - Developers Guide EN.docx

[Stano 143]

I don't know, but I'm filling in a few hundred spaces I'll finish it tomorrow.

Preview:

Clean Code enthusiast probably would point outavoid disinformation, but it allboils’ downs to names could lead developersin a wrong direction, because developers end upwith different understanding of a name.Think ofSetPosition not setting current position ofa memory buffer, say in an instance of a class with a name containing the word“Stream”, to a new position passed as the parameter Value, butinsteadat the position of the memory buffer was set tothat value.

Edited February 24, 2022 by Stano

[Stano 143]

I don't know what and when it delete some spaces. I fixed it. Fixed other errors using Google Translator. To be sure, I put it packed. I don't want to fix / modify it anymore.
I use MS Office 2007!

Object Pascal Style Guide - Developers Guide EN.zip

Edited February 25, 2022 by Stano

[Fr0sT.Brutal 900]

Won't the style guide be like "1. Write some code 2. Launch formatter 3. Examine the result"? 😄 Then only naming stuff is left to learn

[wuwuxin 28]

This has been pestering me for a while

 

For the string type,  should be it "String", or "string",  I saw the Delphi source code mixes the uses.  Some third-party code uses "String", while some uses "string".

[Dalija Prasnikar 1396]

1 hour ago, wuwuxin said:

This has been pestering me for a while

 

For the string type,  should be it "String", or "string",  I saw the Delphi source code mixes the uses.  Some third-party code uses "String", while some uses "string".

If you follow a guideline that all reserved words (keywords) are written in small caps, then string which is a keyword should be written as "string".

[wuwuxin 28]

56 minutes ago, Dalija Prasnikar said:

If you follow a guideline that all reserved words (keywords) are written in small caps, then string which is a keyword should be written as "string".

Really, so it is a reserved word?  I had thought it is a Class type, hence it should be "String"

Edited May 2, 2022 by wuwuxin

[Dalija Prasnikar 1396]

14 minutes ago, wuwuxin said:

Really, so it is a reserved word?  I had thought it is a Class type, hence it should be "String"

In Delphi string is separate data type and strings are not classes  https://docwiki.embarcadero.com/RADStudio/Alexandria/en/String_Types_(Delphi)

 

https://docwiki.embarcadero.com/RADStudio/Sydney/en/Fundamental_Syntactic_Elements_(Delphi)#Reserved_Words

[wuwuxin 28]

8 minutes ago, Dalija Prasnikar said:

In Delphi string is separate data type and strings are not classes  https://docwiki.embarcadero.com/RADStudio/Alexandria/en/String_Types_(Delphi)

 

https://docwiki.embarcadero.com/RADStudio/Sydney/en/Fundamental_Syntactic_Elements_(Delphi)#Reserved_Words

Thank you for the link.  On one hand, string is listed as a reserved work, on the other hand, it also says "System.String" is an alias for "UnicodeString"..........