Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2020-08

FPC coding standards

10 messages · 4 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Dwight Schauer

Hello FPC Pascal users,

Is there a default ptop.cfg somewhere that follows the FPC coding standards?

https://wiki.freepascal.org/Coding_style

I'm not looking to submit any PR in the near future, I just want to be able to automatically reformat my code to conform to what I consider a reasonable standard, rather than having to enforce that manually.

Or config for any other invoked from the command line reformatting tool. I don't use IDEs in my regular development work flow (so if Lazarus has this feature, and it can't be invoked from the command line, it won't help me).

The default config generated by ptop definitely does not conform to the standards...

I guess I could write my own ptop.cfg for this... But it seems like with "Some people might think that the coding style used in the FPC compiler and base RTL (run-time library) source code is a little bit strange. But it has been in use for a lot of years and is not subject to discussion. So take the following as a standard to be used." that there should be tool configuration that can do that automatically.

With C/C++ even if I'm just working on my own stuff (not in a team), I can use tools like indent or clang-tidy. I know, FPC is not C/C++, but is still nice to be able to have some tool enforce a consistent style regardless what language I'm using.

Sincerely,

Dwight Schauer

Sven Barth
to Dwight Schauer

Dwight Schauer via fpc-pascal schrieb am
Di., 18. Aug. 2020, 08:45:

The default config generated by ptop definitely does not conform to the standards...

There is no default configuration, because there is not one default standard. While some things are a given (lowercase identifiers, no spaces between identifiers and e.g. operators) the reminder simply depends on the surrounding code which differs slightly from unit to unit (in the RTL sometimes even inside the same unit).

Rule of thumb is that contributions should fit into the existing style.

Regards,
Sven

Dwight Schauer
to Sven Barth
Sven Barth wrote
... There is no default configuration, because there is not one default standard. ...

Understood.

Rule of thumb is that contributions should fit into the existing style.

<digress>In general when it comes to programming it is better to let programmers focus on content, not style (especially when there is supposed to only be one style in a given source file).

One could argue that lack of standardization (and tools to enforce thos standards) cause programmers to do menial tasks that computers can do much better at....</digress>

I guess I will need to make my own configs for ptop if I don't want to be forced to manually focus on style...

It seems ptop does not understand function/procedure modifiers. https://www.freepascal.org/docs-html/ref/refsu3.html

Maybe it does support/understand those, I'll just need to dig through the configs, as theire is mention of "modifier" or "modifiers" in the default config output. Of hand I don't see a "nocrbefore", but I see functions have a type as the last item, but no modifiers...

The default config for ptop does not understand asm, but there is blank entry for it, and I see that giving it the same rules as begin works fine.

Is there a more robust code reformatter (command line / batch oriented) that can used with free pascal? (before I start digging in to making ptop work to remove one's focus from style and put it solely on content?)

Sincerely,
Dwight Schauer

Sven Barth
to Dwight Schauer

Dwight Schauer via fpc-pascal schrieb am
Di., 18. Aug. 2020, 13:55:

Is there a more robust code reformatter (command line / batch oriented)

that can used with free pascal? (before I start digging in to making

ptop work to remove one's focus from style and put it solely on content?)

Not that I know. Most formatters will barf on some of the syntax extensions that FPC provides (see the Jedi Code Formatter that barfs on generic syntax). Even ptop might fail on newer language extensions...

So improving ptop might indeed be the way to go if you want that.

Regards,
Sven

Dwight Schauer
to Sven Barth
Sven Barth wrote 6 lines
Not that I know. Most formatters will barf on some of the syntax extensions that FPC provides (see the Jedi Code Formatter that barfs on generic syntax). Even ptop might fail on newer language extensions... So improving ptop might indeed be the way to go if you want that.

Thanks.

I see what I can do with ptop config and if need be see what it will take to improve ptop. Or investigate starting over with pparser, pastree, paswrite, as I'm already looking at those for some other things.
https://wiki.lazarus.freepascal.org/fcl-passrc

Sincerely,
Dwight Schauer

Sven Barth
to Dwight Schauer

Dwight Schauer via fpc-pascal schrieb am
Di., 18. Aug. 2020, 20:38:

Show quoted text 15 lines
On Tue, 2020-08-18 at 14:11 +0200, Sven Barth wrote: > Not that I know. Most formatters will barf on some of the syntax > extensions that FPC provides (see the Jedi Code Formatter that barfs > on generic syntax). Even ptop might fail on newer language > extensions... > > So improving ptop might indeed be the way to go if you want that. Thanks. I see what I can do with ptop config and if need be see what it will take to improve ptop. Or investigate starting over with pparser, pastree, paswrite, as I'm already looking at those for some other things. https://wiki.lazarus.freepascal.org/fcl-passrc

Might be the even better solution as fcl-passrc will be better maintained due to it being used for both the documentation utility fpdoc as well as pas2js.

Regards,
Sven

Marco van de Voort
to Sven Barth

Op 2020-08-18 om 23:01 schreef Sven Barth via fpc-pascal:

Show quoted text 13 lines
I see what I can do with ptop config and if need be see what it will take to improve ptop. Or investigate starting over with pparser, pastree, paswrite, as I'm already looking at those for some other things. https://wiki.lazarus.freepascal.org/fcl-passrc Might be the even better solution as fcl-passrc will be better maintained due to it being used for both the documentation utility fpdoc as well as pas2js.

Parsers for compilers or source transformation usually discard whitespace asap, while editor and formatting parsers don't. Usually they are different beasts.

Dwight Schauer
to Marco van de Voort
Marco van de Voort wrote 9 lines
Op 2020-08-18 om 23:01 schreef Sven Barth via fpc-pascal: > Might be the even better solution as fcl-passrc will be better > maintained due to it being used for both the documentation utility > fpdoc as well as pas2js. > Parsers for compilers or source transformation usually discard whitespace asap, while editor and formatting parsers don't. Usually they are different beasts.

The only signifiicant whitespace I'm concerned about is that found in string literals and in comments. Other whitespace or manual formatting does not really apply to any strict standard style conformance. I'm not looking for something that honors personal tweaking here and there.

As far as whitespace in literal strings, I'm sure those don't get mangled for pas2js (other than maybe the escaped characters changing, but the transformed string is still going to be an equivalent one).

Now I've seen formatters for other languages, Go for instance, that sort imports and removes ones that are not referenced.

I'm not looking to set up something that invasive. I just want something that I have a few sets of configs that I'm able to tweak make the code adhere to different standards or formatting style. And have one for the style I prefer, but if I need something to be in someone else's style, no problem. (Which I can currently do with clang- tidy).

clang-tidy in my experience for C/C++ seems to throw away all your whitespace, and reformat according the standard you have chose (which you can tweak). With some exception though as far "all whitespace".

As long as the code only gets alterned into something logically equivalaent, and as long as I can retreive the contents of comments formatted as they were originally, I'm not concerned. (Other than enforcing so many so many spaces after something like // and before it, lining up // on adjacent lines in a configurable manner, etc.)

Sincerely,
Dwight

Michael Van Canneyt
to Dwight Schauer
Dwight Schauer wrote 40 lines
On Tue, 2020-08-18 at 23:17 +0200, Marco van de Voort via fpc-pascal wrote: > Op 2020-08-18 om 23:01 schreef Sven Barth via fpc-pascal: > > Might be the even better solution as fcl-passrc will be better > > maintained due to it being used for both the documentation utility > > fpdoc as well as pas2js. > > > Parsers for compilers or source transformation usually discard > whitespace asap, while editor and formatting parsers don't. Usually > they > are different beasts. The only signifiicant whitespace I'm concerned about is that found in string literals and in comments. Other whitespace or manual formatting does not really apply to any strict standard style conformance. I'm not looking for something that honors personal tweaking here and there. As far as whitespace in literal strings, I'm sure those don't get mangled for pas2js (other than maybe the escaped characters changing, but the transformed string is still going to be an equivalent one). Now I've seen formatters for other languages, Go for instance, that sort imports and removes ones that are not referenced. I'm not looking to set up something that invasive. I just want something that I have a few sets of configs that I'm able to tweak make the code adhere to different standards or formatting style. And have one for the style I prefer, but if I need something to be in someone else's style, no problem. (Which I can currently do with clang- tidy). clang-tidy in my experience for C/C++ seems to throw away all your whitespace, and reformat according the standard you have chose (which you can tweak). With some exception though as far "all whitespace". As long as the code only gets alterned into something logically equivalaent, and as long as I can retreive the contents of comments formatted as they were originally, I'm not concerned. (Other than enforcing so many so many spaces after something like // and before it, lining up // on adjacent lines in a configurable manner, etc.)

You cannot easily do this with the current fcl-passrc. In fact, I would not recommend it.

The comments are not kept and do not appear in the AST built by the parser. There is a way to keep the comments, but all info as to where they should be inserted is lost. There are ways to solve this, but you will never be able to insert all comments again; only some constructs can be recognized and reproduced.

A second problem is that if you use IFDEFS, you will only see the part of your code that corresponds to the conditional branches taken in the code.

If you are concerned with reformatting only, then ptop is the better way to go. It just cares about tokens, and will process all branches of conditional code.

Michael.

Dwight Schauer
to Michael Van Canneyt
Michael Van Canneyt wrote 33 lines
On Tue, 18 Aug 2020, Dwight Schauer via fpc-pascal wrote: As long as the code only gets alterned into something logically > equivalaent, and as long as I can retreive the contents of comments > formatted as they were originally, I'm not concerned. (Other than > enforcing so many so many spaces after something like // and before > it, > lining up // on adjacent lines in a configurable manner, etc.) You cannot easily do this with the current fcl-passrc. In fact, I would not recommend it. The comments are not kept and do not appear in the AST built by the parser. There is a way to keep the comments, but all info as to where they should be inserted is lost. There are ways to solve this, but you will never be able to insert all comments again; only some constructs can be recognized and reproduced. A second problem is that if you use IFDEFS, you will only see the part of your code that corresponds to the conditional branches taken in the code. If you are concerned with reformatting only, then ptop is the better way to go. It just cares about tokens, and will process all branches of conditional code.

Thank you! This is why I asked on on this email list. ptop it will need to be then...

I'm not sure if I can get function/procedure modifiers to work without source code changes (to ptop), but I'll find out... It seems like most everything else works with config tweaks, but I'll need to verify that.

Once again, thanks.

Sincerely,
Dwight Schauer