[CLOSED] What is the Pascal convention?

[guest65109]

Why Class name must be prepend with T? I saw people prepend F, P, I... before variable names. I also found people do not use Button1 as name but rename it to btnClick or something like that. What is the convention used there?

[MarkMLl]

The important thing is to appreciate that it is a convention, rather than a hard and fast stricture of the language. In part, it's a derivative of "Hungarian Notation" which would be overkill on account of Pascal's reliable type checking.

T represents a type. F is a field in a class. P is a pointer to a type. I is an interface.

I can certainly think of at least one language where capitalisation is more than just a convention, but as others have pointed out Pascal is case-insensitive: certainly as far as the ASCII range of characters is concerned.

MarkMLl

[rvk]

Why Class name must be prepend with T? I saw people prepend F, P, I... before variable names. I also found people do not use Button1 as name but rename it to btnClick or something like that. What is the convention used there?

The convention used is from the "Object Pascal Style Guide" (or "CodeGear Coding Style Guide lines").
https://edn.embarcadero.com/article/10280

Since one style is easier to read, Lazarus follows the CodeGear Coding Style Guide lines. Of course, almost anyone will find some points there, that are arguably less readable than other styles. That's OK, just try to follow at least 90%. See the LCL for examples.

https://wiki.freepascal.org/DesignGuidelines

The btn prefix for Button1 is also used in some C# coding conventions.
https://www.c-sharpcorner.com/UploadFile/8a67c0/C-Sharp-coding-standards-and-naming-conventions/
So they should look familar.

[Thaddy]

Note the compiler itself has a completely different coding style... Also by convention...

[howardpc]

I think it is more accurate to say that the compiler source exhibits various coding styles (plural). Unless by "style" you mean something considerably broader than what the term is generally understood to mean.
You can't force volunteers to write according to a particular narrow style definition. You have the sanction of rejecting contributions. But that is short-sighted if the quality of the code is very high and it is designed to be easy to maintain, but fails to adhere to a preferred style convention.
In a commercial environment, of course, the project leader has other levers s/he can apply to get employees to conform.
At some levels coding is an art as much as it is a science or a mechanical application of technique.

[marcov]

Why Class name must be prepend with T? I saw people prepend F, P, I... before variable names. I also found people do not use Button1 as name but rename it to btnClick or something like that. What is the convention used there?

Borland Style Convention. Just the convention that Borland used for Delphi sources, adopted by most people.

Note that there are some underlying reasons for some things, like having an unified identifier namespace rather than separate normal,type and macro(const) namespaces like plain old C had, and that some of its derivatives also observe.

Similarly the F field convention is to leave the identifier without f free for the property

[valdir.marcos]

Note the compiler itself has a completely different coding style... Also by convention...

https://wiki.freepascal.org/Coding_style

[mangakissa]

Spaces

Don't use spaces around operators, colons, parentheses etc.

{ correct }
p:=p+i;

{ incorrect }
p := p + i ;

I really don't like it if all code is written without spaces. It reads terrible.

[PascalDragon]

I think it is more accurate to say that the compiler source exhibits various coding styles (plural). Unless by "style" you mean something considerably broader than what the term is generally understood to mean.
You can't force volunteers to write according to a particular narrow style definition. You have the sanction of rejecting contributions. But that is short-sighted if the quality of the code is very high and it is designed to be easy to maintain, but fails to adhere to a preferred style convention.
In a commercial environment, of course, the project leader has other levers s/he can apply to get employees to conform.
At some levels coding is an art as much as it is a science or a mechanical application of technique.

That there are multiple styles right now in the compiler's sources is for historic reasons. We have a style in the compiler that we're gearing towards and we do reject contributions that do not adhere to this (especially if they are bigger contributions, single line patches are a different topic).  The link provided by valdir.marcos lists some part of the style, though it is a work in progress to document it.

Spaces

Don't use spaces around operators, colons, parentheses etc.

{ correct }
p:=p+i;

{ incorrect }
p := p + i ;

I really don't like it if all code is written without spaces. It reads terrible.

It does not matter what you like or not (I personally don't like that the begin is on a separate line for example), but when you're working on a shared project (no matter if Open Source or in a company) you adhere to the guide lines of that project. When in Rome, do as the Romans do...

[guest65109]

It does not matter what you like or not (I personally don't like that the begin is on a separate line for example), but when you're working on a shared project (no matter if Open Source or in a company) you adhere to the guide lines of that project. When in Rome, do as the Romans do...

Does the Pascal world have source formatting tools like AStyle? Just fire it up and done, everything is beautiful and sane again. These tools are very sophisticated and reliable now so don't fear they will messed your source up 

[MarkMLl]

Yes, and just like C nobody agrees how things should be laid out. In other words it's down to the project managers, and you don't argue with it.

MarkMLl

[guest65109]

The thing I hate most is prepending a T before any class name. Why? We already know it's a Type. In many languages, Types are equivalent with Classes. It doesn't make any sense at all. The same for prepending a P before pointer name. I have seen many examples of how stupid and ridiculous it is. The most obvious example: double pointer (PP). By following this brain dead convention, you have to do a lot of typedefs. These typedefs are useless. You accuse C of using so many typedefs, but you don't see you are, too.

For example, we have a record Foo.

Pointer to Foo: type PFoo = ^Foo;

Pointer to pointer to Foo: type PPFoo = ^PFoo;

How many `P` will you prepend to it if you have to make a pointer to a pointer to a pointer to Foo?

[MarkMLl]

Well don't do it then. You don't have to do it, as several people have explained to you it's a convention rather than a hard-and-fast syntactic rule.

But if you don't do it you're making life more difficult for people from whom you ask help. And if you don't stick to project conventions you're making extra work for whoever processes your contributions.

MarkMLl

[guest65109]

Yes, and just like C nobody agrees how things should be laid out. In other words it's down to the project managers, and you don't argue with it.

MarkMLl

Yes. I know. Bad practices build up over time and it's very hard to change. I can't get up early for more than ten years despite how hard I tried 

[soerensen3]

I rarely use pointers, let alone double pointers. There might be use cases for double pointers but I cannot even imagine one.