Jump to content
Guest

A book about Object Pascal Style Guide

Recommended Posts

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.

 

  • Like 1

Share this post


Link to post

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

  • Like 1

Share this post


Link to post
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.

Share this post


Link to post
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.

  • Like 1

Share this post


Link to post

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.

  • Like 1

Share this post


Link to post
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.

Share this post


Link to post
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 by Stano

Share this post


Link to post
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.

  • Like 1

Share this post


Link to post

@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?

Share this post


Link to post
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.

Share this post


Link to post
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? 

Share this post


Link to post

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

Share this post


Link to post
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:classic_wacko:

Object Pascal Style Guide - Developers Guide EN.docx

doc1.thumb.png.3562e6e5c76b880692ffb8a9cb11c30e.pngdoc2.thumb.png.6b4c5c017227f8e2e47170cf3772f017.png

 

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

Edited by toms

Share this post


Link to post

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 by Stano

Share this post


Link to post

I don't know, but I'm filling in a few hundred spaces:classic_rolleyes: 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 by Stano

Share this post


Link to post

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 by Stano

Share this post


Link to post

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

  • Like 2

Share this post


Link to post

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".

Share this post


Link to post
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".

  • Like 1

Share this post


Link to post
Posted (edited)
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 by wuwuxin

Share this post


Link to post
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

  • Thanks 1

Share this post


Link to post
8 minutes ago, Dalija Prasnikar said:

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".......... 

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×