Re: [fpc-pascal] FPC coding standards
On Wed, 2020-08-19 at 02:03 +0200, Michael Van Canneyt wrote: > > 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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC coding standards
On Tue, 18 Aug 2020, Dwight Schauer via fpc-pascal wrote: 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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC coding standards
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.) Sincerely, Dwight ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC coding standards
Op 2020-08-18 om 23:01 schreef Sven Barth via fpc-pascal: 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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC coding standards
Dwight Schauer via fpc-pascal schrieb am Di., 18. Aug. 2020, 20:38: > 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 > > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC coding standards
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 Sincerely, Dwight Schauer ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC coding standards
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 > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC coding standards
On Tue, 2020-08-18 at 11:08 +0200, Sven Barth via fpc-pascal 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. 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 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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC coding standards
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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] FPC coding standards
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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
