What's the point with these auto generated comments {TForm1}

[Silvio Clécio]

...
So Maciej: it is a BAD idea to remove it. It discourages commenting your code....

Well, I also agreed Maciej in my last comments. (three, but ...) 

[Silvio Clécio]

...
The whole template should be configurable. Then people can add any comments they like.

It's really a good news.

[JuhaManninen]

So Maciej: it is a BAD idea to remove it. It discourages commenting your code....

That is utter nonsense. A comment which only repeats the obvious from previous line is a BAD comment. It is a warning example of how a comment should not be.
During the years I got the impression that most Delphi programmers consider those comments useless. They either delete the comments or just leave them untouched, in which case they eternally pollute the code for anybody reading it.
I am surprised there is now a small (3 people) but loud minority who consider those comments extremely important.

[Thaddy]

So Maciej: it is a BAD idea to remove it. It discourages commenting your code....

That is utter nonsense. A comment which only repeats the obvious from previous line is a BAD comment. It is a warning example of how a comment should not be.
During the years I got the impression that most Delphi programmers consider those comments useless. They either delete the comments or just leave them untouched, in which case they eternally pollute the code for anybody reading it.
I am surprised there is now a small (3 people) but loud minority who consider those comments extremely important.

Then you did not read properly.
The comment is there to be expanded. Just like Tform1 is there to be renamed. It is a full design approach. If you consider it useless at least appreciate the background.
What I wrote here is really how it went. I was there when Chuck explained it.
There is logic in it: hit a space or a : , maybe a return, after the Tform (or any of the generated comments) and start f*cking commenting straight away. THAT's the point!
If it hardly got used and if it went under the radar for lack of documentation, in French: "soit", but there is a use for it and it is by original design.... and makes the design even more consistent.
And in Delphi it is well implemented.

[Thaddy]

Maybe replace it in objfpc mode into TODO: F*cking comment your code or I will comment it out!
Fine by me

It is not a relic: it has a function.
Probably requires a {$TEAM +/- ON/OFF} mode as well. I work like the above, people know that. My teams knew that.
I'll ask Chuck or some other old Borlander to confirm this if you want?

See it as an invitation to comment your code because that is what it means.

[kupferstecher]

When I started programming with Lazarus this comment encouraged me to place 'manual' declaration at that position, releaving me of the fear that my declarations could break the automatic generation by the designer or resulting in errors. So these two comments I read somehow like that:

Code: Pascal  [Select][+][-]

1. type
2.   TForm1 = class(TForm)
3.       Panel1: TPanel;
4.       Button1: TButton;
5.     private
6.       {user declarations}
7.     public
8.       {user declarations}
9.   end;

And thats what I also thought is the purpose of the comments, to guide to the correct place of the declarations.


Thaddys argument that it could be used for a real comment I couldn't follow.

Code: Pascal  [Select][+][-]

1. //For commenting I always use the double slash,
2. //even if its a multiline comment

[Silvio Clécio]

When you remove the comments replacing it with something, it sounds good, but removing comments keeping empty areas, it is very ugly for my eyes and sounds very weird for beginners. Some examples (please see all of them):

good, just a empty form:

type
  TForm1 = class(TForm)
  end;

good, just hints helping beginners (the comments below is merely for illustrating):

  TForm1 = class(TForm)
  private
    { Hey dude, put your private things here and keep this formatting. }
  public
    { Hey dude, put your public things here and keep this formatting. }
  end;

good, my stuff replaced the comments (button1 added through IDE):

  TForm1 = class(TForm)
    Button1: TButton;
  private
    FMyProp: Integer;
  public
    property MyProp: Integer read FMyProp;
  end;

good, just a alert:

  try
    DoSomeNormalExceptionCode;
  except
    // no problem, silent exception
  end;

good, just a convention:

var
  GEnv: TEnt;
  { please add G for global variable prefixing. }

weird, empty areas:

  TForm1 = class(TForm)
  private

  public

  end;

weird, empty scopes:

var
  Form1: TForm1;

implementation

{$R *.lfm}

initialization

finalization

end.

weird, unused units, we just need "uses Forms;":

uses
  Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs;

type
  TForm1 = class(TForm)
  private

  public

  end;

weird, useless comments and ifdefs:

uses
  {$IFDEF UNIX}{$IFDEF UseCThreads}
  cthreads,
  {$ENDIF}{$ENDIF}
  Interfaces, // this includes the LCL widgetset // OK, but I just open my lpr exactly for removing this comment :-D
  Forms, unit1
  { you can add units after this };  // really a big useless comment, the IDE  automatically add most units here dude :-p

for the case above it should be:

uses
{$IFDEF UNIX}
  CThreads,
{$ENDIF}
  Interfaces, Forms, unit1;

[Thaddy]

Thaddys argument that it could be used for a real comment I couldn't follow.

Code: Pascal  [Select][+][-]

1. //For commenting I always use the double slash,
2. //even if its a multiline comment

FYI:
C style // commenting was not available in Delphi 1 so the option of using the double forward slash was not available.

I think they would have still gone for the multiline comment solution, though
I tend to use // for one liners but { and or (* for multiline comments. The latter if I am commenting on a e.g. compiler directive.

Btw. The feature should be used like this:

Code: Pascal  [Select][+][-]

1.     private
2.       {private declarations
3.         note that variables fX and fY *must* have private scope
4.         because their values depend on internal processing by their
5.         control routine. A direct read or write can therefor have
6.         indetermined results. They depend on the hardware readout that is done
7.         in the process routine. They are stored here because they serve to caluclate
8.         the delta between last values and new values, which is exposed through the X
9.         and Y properties.
10.         See the technical design document page 1132 ad 24
11.       }
12.        fX:integer;
13.        fY:Single;
14.      procedure process(x:integer;y:single);
15.     public
16.       {public declarations
17.        Note that properties X and Y *must* be accessed through getters and setters
18.        because they are under hardware control. It is forbidden to read them out
19.        directly because the state of their value is in that case indetermined.
20.        See the technical design document page 1132 ad 24
21.       }
22.      property X:integer read getx write setx;
23.      property Y:integer read gety write sety; // note: this is not a single. Its storage field is!
24.      

The long length of the comments is warranted here by the complex relations in the underlying code.
Normally you'd prefer shorter comments, or leave them out.

[Graeme]

These are actually useful and more powerful than you think - as implemented in Delphi, that is.

I fail to see it - sorry. I see no functionality in those comments - they simply state the obvious.

[Graeme]

The comment is there to be expanded.

Yet NOBODY expands those comments - in the 20+ years that I've been using Delphi and FPC, I have never come across another developer that actually thought those comments were useful. In fact, I've seen tons of code over the years will those comments in place, un edited - exactly like the form designer created them. So utter useless.

The original Borland developers might have had all good intentions, but clearly that is not the way anybody else sees it. Borland had many other good intentions too, and many did not pan out that well either. Like RAD design, yet with RAD you normally find terrible designed software, where business logic gets dumped into the form units (GUI layer) with no clear separation of GUI, Business Logic and Persistence. That goes totally against good OOP design.

There is logic in it: hit a space or a : , maybe a return, after the Tform (or any of the generated comments) and start f*cking commenting straight away. THAT's the point!

Then learn to touch type! Typing the { and } symbols doesn't even take a second. So it's not like it is going to slow you down at all typing those comment markers.

Oh but wait, what if my coding style guide say I must always use // to start comments. So by having the form designer insert {..} based comments, and I have no control over the comment style setting the form designe user, the form designer is now causing me more work, because now I first need to delete that useless comment (which uses the wrong coding style guide) before I can type my actual comments starting with the // style comments.   


There is an expression: "You are trying to make a mountain out of a mole hill."

[Graeme]

uses
{$IFDEF UNIX}
  CThreads,
{$ENDIF}
  ...;

There is a big difference between the above and the one with the UseCThread define. The above says if you use Unix, always bind to a C library too, even for very simple applications. Sometimes you don't want to do that, and that is exactly what the UseCThreads define did. Yes it might not look so nice, but it actually has a purpose.

Saying that, I still prefer to manually add the "cthread" to the uses clause  - ONLY when I know my application actually uses multi threading.

[Silvio Clécio]

...
Saying that, I still prefer to manually add the "cthread" to the uses clause  - ONLY when I know my application actually uses multi threading.

Indeed. IIRC, some months ago we didn't have the missing thread-driver alert, today, if you try to use a thread without link some of them to your application, you will get the following message at your console:

"This binary has no thread support compiled in.
Recompile the application with a thread-driver in the program uses clause before other units using thread."

So this {$IFDEF}cthread{$ENDIF} pre-declaration should be removed and the message above could be edited to:

"This binary has no thread support compiled in.
Recompile the application with a thread-driver (e.g. cthreads) in the program uses clause before other units using thread."

[Thaddy]

The original Borland developers might have had all good intentions, but clearly that is not the way anybody else sees it. Borland had many other good intentions too, and many did not pan out that well either. Like RAD design, yet with RAD you normally find terrible designed software, where business logic gets dumped into the form units (GUI layer) with no clear separation of GUI, Business Logic and Persistence. That goes totally against good OOP design.

I don't see what it has to do with bad design. That's a completely irrelevant remark and not on topic. Class completion will also invoke this feature - on any class you define. The feature also includes renaming support.
My example wasn't stating the obvious btw: it describes a case where at least in teams it is better to describe what happens just in case somebody sees an "optimaization"
Commenting code is invaluable. The IDE simply implements one way to get you started. It is a good feature when used properly and I know of many companies that actually use it as I described.

[Graeme]

Commenting code is invaluable.

No argument there... If the code comments have something useful to contribute. Stating the obvious is not useful.

It is a good feature when used properly and I know of many companies that actually use it as I described.

And that's the problem... "when used properly" - which clearly nobody bothers with.

BTW: I use my keyboard properly as described too.   When I want code comments that actually contribute something, I simply type them in where needed. I don't need an IDE that thinks it is more clever than I am.

[Thaddy]

Our opinions clearly differ. I'd like to keep it as default.