Coding style

From Free Pascal wiki

English (en) français (fr) русский (ru)

FPC compiler and RTL

Introduction

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.

Keywords

Write all keywords in all lower snake_case. There is no need to make them unreadble by writing them in upper case. Modern IDEs support syntax highlighting, so keywords will be easily recognizable.

Spaces

Don't use spaces around operators, colons, parentheses etc.

{ correct } 
p:=p+i;

{ incorrect }
p := p + i ;

Spaces in parameter lists. TODO: ???

function do_this(a: tdef; var b: tdef): boolean;

Spaces in variable lists. TODO: ???

var
  a,b,c : tprocdef;

TAB characters

Do not use TAB characters (ASCII HT, 0x09). There is no standard default TAB setting, so the look of source files using TAB characters will depend on client settings. This may result in a chaotic view of source files. Align by space characters (also see Indentation).

Indentation

Indentation size is always 2 space characters per level.

Never place a begin on the same line as while..do/if..then/..., but always on its own line (and indent it compared to the while/if/...).

{ correct }
if true then
  begin
  end;

{ incorrect }
if true then begin
  end;

{ incorrect }
if true then begin {...} end;

Newlines

Newlines are set as it is done by most Object Pascal programs (what does this mean? advice: avoid passive voice). Separate subroutines by three newlines, that is, put two blank lines between them.

Comments

Comments should use curly brackets, be lower case and contain a single space between the {}.

{ this is an example of a comment }

Routines

All sections (var, const, begin etc...) after routine header are intended one level.

procedure do_this;
  var
    sym: tsym;
  begin
  end;

No spaces after name and parenthesis for parameters.

procedure do_this(param: integer);
  begin
  end;

Nested functions are intended one level (the same level as other sections like var, const etc...)

procedure do_this;
  var
    i: integer;

  { nested function }
  function getter: boolean;
    begin
    end;

  var
    x: integer;
  begin
  end;

Use result instead of function name for return values.

function getter: boolean;
  begin
    result:=true;
    // wrong!
    //getter:=true;
  end;

Classes/Records

Class sections should appear on the same indention level as the class name.

tloadnode = class(tunarynode)
protected
  fprocdef : tprocdef;
public
  constructor create(v : tsym;st : TSymtable);virtual;
end;

Misc

Please note that the else in consecutive ifs is not indented:

 if x then
   begin
     ..
   end
 else if y then
   begin
     ...
   end;

Split all composite if-conditions over multiple lines, so no "if (x) and (y) then" but

if p1.nodetype=ordconstn and
  not is_boolean(p1.resultdef) and
  not is_enum(p1.resultdef) then
  begin
    ...

(except possibly if x and y are simply boolean variables)

Extraneous parenthesis in if statements: TODO: ???

if (pd.maxparacount>0) then
  ;

Examples

How it looks like can be easily checked by having a look at the FPC sources.

FCL

There are no formal standards. To do: write me.

Other packages distributed with FPC

There are no formal standards. To do: write me.

Lazarus

Since Lazarus and LCL follow Delphi compatibility, a code style similar to the one used in Delphi is used.

If you're writing a patch or an extension for LCL you should follow its code style.

If you're developing your own component, you're free to use any style you like, but it's suggested to use the LCL style, too.

See the Lazarus coding guidelines: DesignGuidelines

For reference, you can find the description of Delphi coding style here

See also