Project templates

I was playing with CGE again and I want to propose new project templates. My proposal is to refit the indentation, rephrase comments, apply Borland/Embarcadero Codibg Style guide to identifiers and use more verbose code (i.e. redundancies as Self and such).

My question is, should we discuss it here or should I just push a pull request? And in case of pull request, a pull per template or a single one with all them?

We can discuss here, or if you want — you can submit a pull request (I suggest to one template first), and let’s discuss in PR. Some of the things you mention – are either already done in my eyes, or I don’t think we should do it :), so they warrant a discussion. At the same time, the discussion will be probably more concrete if I see the exact changes you propose.

IOW, I agree with the spirit of the changes you mention – we want the templates to present a code that is clean, looks standard to a Pascal developer, and we want them nicely documented. I’m not sure do I agree with some exact details you mention :slight_smile: Let’s talk!

Note that we have our own coding conventions Coding Conventions | Manual | Castle Game Engine , though most of Pascal conventions there are deliberately just the same as what I saw in both Lazarus and Delphi codebases.

To address some things you mention:

  1. Indentation and following Embarcadero coding style – sure, we want to follow them in general, our Coding Conventions | Manual | Castle Game Engine are generally consistent with Embarcadero style from what I know. Where do we differ from coding style and indentation?

  2. Rephrase comments: sure, I’m open to improving them. What do you miss?

  3. “Redundancies as Self” – If I understand correctly what you mean (calling methods with Self.Xxx instead of Xxx) – this is something I explicitly do not want. It would be a lot of Self. additions that are ultimately unnecessary. Pascal says you can omit Self in Self.Xxx, just like most other languages, and we use this feature. From what I see, so does most existing Lazarus and Delphi codebase.

    Though it is possible I misunderstand this point, i.e. maybe I don’t understand what you meant by “redundancies as Self and such”. Discussing this in PR is absolutely welcome :slight_smile:

1 Like

I’ve read your Coding Conventions and I’ve found they’re quite different than mine. Actually I do the opposite in some cases :sweat_smile: (for example, units order in uses clause). I think my proposal won’t be accepted; no problem with this though.

Since it’s easy to change CGE templates I think I’ll finish my templates, then upload to GitHub as a new project so people can use them, and discuss them and maybe adapt some parts to the current templates.

Understood, all good.

I’m still open to talking about it. Because I think CGE coding conventions generally follow Lazarus / Delphi codebases I saw, I really didn’t want to propose something controversial there :slight_smile:

E.g. units order to which you refer, Coding Conventions | Manual | Castle Game Engine : the idea is that in most applications, it should not matter at all, but in edge-cases, we want application-scoped identifiers to obscure engine identifiers, and engine identifiers to obscure standard units. But, in the ideal world, there should be no conflicts thus no obscuring. I think this follow general notion. E.g. I’m looking now at Lazarus unit CocoaWSComCtrls having uses clause:

  // RTL, FCL, LCL
  MacOSAll, CocoaAll,
  Classes, LCLType, SysUtils, LCLMessageGlue, LMessages,
  Controls, ComCtrls, Types, StdCtrls, LCLProc, Graphics, ImgList,
  // WS
  // Cocoa WS
  CocoaPrivate, CocoaScrollers, CocoaTabControls, CocoaUtils,
  CocoaWSCommon, CocoaTables, cocoa_extra, CocoaWSStdCtrls, CocoaGDIObjects, CocoaButtons;

So LCL does follow similar conventions. Units order is roughly from “most general” to “most local / specific”.

Anyhow, this is all subject to discussion and possible improvements :slight_smile: