Code layout

[doctorjellybean]

I like to organize my code into sections, so that I don't have to scroll up and down to find a specific procedure, function, etc.

Now it appears to me, unless I'm mistaken, that certain (if not all) function routines have to appear first after {$R *.dfm} before any procedure routines. Is there a specific rule regarding this?

Also, does comments add to the memory usage/application size? Quite a few routines have comments to remind me what the heck it is about.

I have to say I don't like the method D2007 uses to insert OnClick events. Older versions generated the procedure after the last event, and was easier to find. D2007 seems to stick it anywhere but last

 

[Opieo]

Unless something has changed in D2007, comments should have no impact on the application size. Only on the storage space of the uncompiled files. When compiling, Delphi ignores / discards the comments as they technically have zero value to the program.

Hence why decompiling always comes with no comments =)

~
Chuck Norris is the reason Waldo is hiding.

 

[Glenn9999]

(functions first before procedures) Is there a specific rule regarding this?

No. You can place functions/procedures in any order you like in the file. Locating them can be useful either by searching for the name or use the code folding option in the editor.

Also, does comments add to the memory usage/application size?

No. Comments have nothing to do with the compiled program.

I have to say I don't like the method D2007 uses to insert OnClick events.

I think it places new events at where your cursor was placed last.

----------
Measurement is not management.

 

[CADTenchy]

I have found that functions seem to need to come before (above) any procedures calling them?


Steve (Delphi 2007 & XP)

 

[doctorjellybean]

I have found that functions seem to need to come before (above) any procedures calling them?

Same here, that is why I wasn't sure.

I think it places new events at where your cursor was placed last.

Correct. I have just tried that, and it appears to work that way.

It is kinda strange how we don't notice the little things until we actually pays attention to it.

 

[Duoas]

The IDE inserts routines into your unit alphabetically, so you can find them just by going to the right place in the alphabet.

The only order Delphi imposes on the order of elements (within their appropriate section) is that they be declared before they are used.

So the following is legal

interface

function foo: boolean;
procedure bar;

implementation

procedure bar;
  begin
  end;

var quux: string;

function foo: boolean;
  begin
  end;

 

[roo0047]

@Duoas - Your statement...

The only order Delphi imposes on the order of elements (within their appropriate section) is that they be declared before they are used.

...is true for GLOBAL funtions and procedures in a UNIT as you have demonstrated in your example.


Not true for funtions and procedures belonging to a CLASS in the implementation section of a FORM. They can be in any order, regardless of public or private.

HTH


Roo
Delphi Rules!

 

[Duoas]

I didn't think of that, but the same still applies. Things must be declared before you use them. Certain cases allow you to go on faith for a short bit though, but only when a definition is incomplete.

For example:

type
  pFoo = ^tFoo;  // Assumes tFoo exists somewhere.
  tFoo = record
         foo: integer;
         bar: pFoo
         end;

This isn't a problem in practice, since a pointer takes the same space no matter what it is pointing at.

For a class example

type
  tFoo = class;

  tBar = class
    public
      foo: tFoo;  // Same
    end;

Again, this isn't a problem because foo is really just a pointer to the object underneath the shiny veneer, and again all (far) pointers have the same storage requirements.

Likewise:

type
  tFoo = class
    public
      property foo: integer read f_get_foo;
    protected
      function f_get_foo: integer;
    end;

Still not a problem since n


Oh

Hmm. I see what you are saying.
Your point is moot, since the methods are already declared in the interface section. Any procedure you name in the interface section of a unit is treated as a forward declaration. Once declared, you can mix things up any way you want.

function foo: integer; forward;
function bar: integer; forward;
function baz: integer; forward;

function baz: integer;
  begin result := bar end;

function bar: integer;
  begin result := foo end;

var myint: integer = 42;

function foo: integer;
  begin result := myint end;

begin
writeln( baz )
end.

Believe it or not, a good Pascal compiler can handle this in a single pass.

Heh heh heh...


Oh, inside a class declaration my Delphi compilers always want to see fields before methods before properties in each section. I don't know if that is required though... but since it is an Apple/Borland construct I suppose existing compilers are the documentation...